Build bitmaps incrementally instead of starting with a list when reading
sieve files. This would reduce the peak memory use which currently occurs
just after reading the sieve file.

Add options to perform PRP and P-1 tests on candidates at the bottom of the
sieve range when it becomes efficient to do so.

Design a lookup table to replace bitmaps once they become too sparse.

Add code to do internal self tests and benchmarks.

Write a utility program srdata to manage factors, prp residues, etc.

Add the ability to accept a variable k in a sequence expression along with
--kmin --kmax. For example `srsieve --kmin 100 --kmax 200 "k*5^n+1" would
sieve all sequences 100*5^n+1, 101*5^n+1, ..., 200*5^n+1.

Add an option to remove a sequence from the sieve when a prime term is
found. This would really only be useful in conjunction with the variable k
option above.

Write a vec_mulmod function in assembler, for use in the giant steps:
vec_mulmod(V,len,a,p) { V[i] = mulmod(V[i],a,p) for 0 <= i < len }.

Add an assembler version of mul5mod64. There are probably gains to be had by
using CMOVs to eliminate some of the branches. *** Maybe not. GCC does this
very well for mul5mod32 already, but in mul5mod64 there don't seem to be
enough scratch registers available for the same approach to work. ***

Accept sequences of the form (k*b^n+c)/d. This can be done by finding
d=p1^m1*p2^m2*...*pk^mk and then sieving k*b^n+c as usual except testing
whether pi^(mi+1) divides k*b^n+c instead of sieving pi. Increase
small_sieve_limit to include all pi and it won't affect the speed of the
main sieves at all.

Add a --weight switch to make srfile calculate sieve weight for each sequence.

Add a --twin switch to make srfile remove non-twin terms from sieve files
(terms for k*b^n+c where neither k*b^n+c+2 nor k*b^n+c-2 are in the sieve).

Make subsequences use parent sequence bitmaps instead of creating their own.
Use the bitmap scheme from version 0.2.x which was faster to access than the
version 0.3.x scheme, and probably causes less memory fragmentation.

Avoid calculating 1/k (mod p) more than once when more than one sequence
shares the same k.

Optimise building of the table of 1/b^d (mod p) values. Currently it is not
efficient when the largest d-value is much smaller than Q, or when there are
much less than Q d-values.

Use base 4 arithmetic for base 2^2 subsequences. Work out which other cases
are worthwhile. (2^3 and 3^2 probably are).

Write a bsgs setup routine specialised for sieves with c = +/-1, saving one
mulmod per sequence.

When Q=1, delay calculating 1/b (mod p) until certain that it will be used.

Speed up the file processing code. Simple AWK scripts are much faster.

Write a new version of is_factor() for use by srfile that can handle
arbitrarily large factors (e.g. factors found by P-1 or ECM).

prime_sieve() currently sieves odd numbers p=x*2+1 for primes. Write a
version that sieves fermat divisors p=x*2^y+1 for primes instead, where y
can be determined at runtime. Maybe even a third verison that sieves for
p=a,b,...(mod M) as given by the user with the --mod=M,a,b,c,... switch.

When per-subsequence filters are being employed, build a table of the number
of baby and giant steps to use for each quantity of subsequences passing the
filters, then set m and M from the table at each bsgs iteration depending on
the result of filtering.

If there are f (f small) different per-subsequence filters, choose one of
2^f pre-computed filter lists instead of building a new one each time
build_filtered_list() is called.

Install filters for subsequences with all terms of the form rA^2+/-B^2 where
r is small (r <= 6?) using the form of primes with r as a quadratic residue.
e.g. if r=3 and the the second term is negative then p=1,11 (mod 12).

If gcd_i(d_i) = x then work in base b'=b^x with Q'=Q/x and d'=d/x.
