[(1/7)] New optab framework for widening multiplies

This patch should have no effect on the compiler output. It merely 
replaces one way to represent widening operations with another, and 
refactors the other parts of the compiler to match. The rest of the 
patch set uses this new framework to implement the optimization 
improvements.

I considered and discarded many approaches to this patch before arriving 
at this solution, and I feel sure that there'll be somebody out there 
who will think I chose the wrong one, so let me first explain how I got 
here ....

The aim is to be able to encode and query optabs that have any given 
input mode, and any given output mode. This is similar to the 
convert_optab, but not compatible with that optab since it is handled 
completely differently in the code.

(Just to be clear, the existing widening multiply support only covers 
instructions that widen by *one* mode, so it's only ever been necessary 
to know the output mode, up to now.)

Option 1 was to add a second dimension to the handlers table in optab_d, 
but I discarded this option because it would increase the memory usage 
by the square of the number of modes, which is a bit much.

Option 2 was to add a whole new optab, similar to optab_d, but with a 
second dimension like convert_optab_d, however this turned out to cause 
way too many pointer type mismatches in the code, and would have been 
very difficult to fix up.

Option 3 was to add new optab entries for widening by two modes, by 
three modes, and so on. True, I would only need to add one extra set for 
what I need, but there would be so many places in the code that compare 
against smul_widen_optab, for example, that would need to be taught 
about these, that it seemed like a bad idea.

Option 4 was to have a separate table that contained the widening 
operations, and refer to that whenever a widening entry in the main 
optab is referenced, but I found that there was no easy way to do the 
mapping without putting some sort of switch table in 
widening_optab_handler, and that negates the other advantages.

So, what I've done in the end is add a new pointer entry "widening" into 
optab_d, and dynamically build the widening operations table for each 
optab that needs it. I've then added new accessor functions that take 
both input and output modes, and altered the code to use them where 
appropriate.

The down-side of this approach is that the optab entries for widening 
operations now have two "handlers" tables, one of which is redundant. 
That said, those cases are in the minority, and it is the smaller table 
which is unused.

If people find that very distasteful, it might be possible to remove the 
*_widen_optab entries and unify smul_optab with smul_widen_optab, and so 
on, and save space that way. I've not done so yet, but I expect I could 
if people feel strongly about it.

As a side-effect, it's now possible for any optab to be "widening", 
should some target happen to have a widening add, shift, or whatever.

Is this patch OK?

Andrew

[(1/7)] New optab framework for widening multiplies

Commit Message

Patch