Re: midRTL: midRTL generation

[law at redhat dot com]

 In message <20020125191150.GC17305@atrey.karlin.mff.cuni.cz>, Jan Hubicka 
write
 > I will do. I am short on time right now, as I do leave for vacantion at
 > monday evening, but I will do that after returning.
Understood.  Enjoy your vacation.

 > > Correct.  We may even want to make it a longer term goal that all lowering
 > > goes through the optab interface.
 > 
 > Yes, currently the lowering is bit tricky, as for example MUL needs to be
 > lowered by expand_mul and such. Generic interface for that and separating
 > the "middle end code working around missing features of CPU" to single
 > place is nice cleanup.
MUL is an excellent example to look at long term as it's got some interesting
issues for what gets lowered when and how we cleanup redundancies that are
exposed after lowering to target specific RTL.

 > If I understand you correctly, you want to make the virtualizing using the
 > insn descriptors, so there will be two functions never called directly,
Correct, virtualization is the way to go I think.

 > probably gen_call and mid_gen_call and we will always use the pointer
 > obtained using CODE_FOR_call variable and insn table.
Hell, they could both be gen_call.

If we think about this in terms of virtualizing and having independent
recognizers & expanders, then we can have all the gen_XXX things be
static and we don't have to worry about name clases.  One more step
along the long road of cleaning up how much internal crud each module
currently makes available to the other modules.  Anyway, I digress.

 > Other idea I've been playing around is the fact that we probably don't need
 > HAVE_xxx for midRTL at all, as we know the set of features midRTL do support
Yes, I thought about that briefly -- but I'm not sure if it really wins us
much, except for code which is only used when we're working with generic
RTL.  We'll have to see what makes sense as we get further into the 
implementation.

 > In the idea of dropping the mode from generic patterns I see possible
 > issues:
 > 
 > 1) We need to represent somehow that there should be used the mode of patter
 > n.
 >    It can be done by inventing something like CPYmode used at places where
 >    the mode should be used
Sorry.  I don't follow this one.



 > 2) The converison patterns is nice example of case we need multiple modes.
 >    So we would need to express how many modes and what class of modes the
 >    instruction accepts.
 >    Often the operations are not symetric - it makes sense to define UDIV for
 >    integer modes, but not for floating point, so we need to express that
 >    somehow for generic_insn
For truncation & extension it's easy to derive it from the operands, 
similarly for most arithmetic/logicals.

The kinds of places were it falls down (for example) would be the shift 
count -- we've never required that operand to have the same mode as the
item being shifted.

 > So you mean we will have just gen_add function and CODE_FOR_add, not
 > gen_addsi/CODE_FOR_addsi.
Good question.  I hadn't thought of this.

I think we have to keep CODE_FOR_addsi and friends, they should all point
to then insn code for the generic add.

 > I think it will run into issues how to determine the mode of operation 
itself
 > We sometimes do have constructs where the mode is indeterminable from the
 > operands.
There's a few of these.  They may have to be special cased, or more strictly
defined (as in the shift count case mentioned above).

jeff