[LLVMdev] Variable length condition code for SETCC and SELECT?

[B. Scott Michel]

B. Scott Michel wrote:

>B. Scott Michel wrote:
>  
>
>>It'd be easy to hack PromoteOp to make a pass to determine all operands' 
>>promoted value types, take the max, then figure out some way to 
>>re-promote them to maximal promoted value type. Except that this is a 
>>non-optimal solution requiring PromoteOp to potentially traverse the 
>>operand tree twice.
>>
>>Any suggestions or ideas?
>>  
>>    
>>
>Not many suggestions or ideas, given the feedback so far. I'm not sure 
>that two passes down a Node's Operand DAG can be avoided. The first pass 
>would determine the maximal MVT needed, the second pass would generate 
>the promoted Nodes.
>
>In the absence of any suggestions or ideas, it's off to begging 
>forgiveness if the patch confuses people and code. :-)
>  
>
I like talking to myself... and I've been hacking on a two-pass version
of SelectionDAGLegalize::PromoteOp, where the first pass determines the
maximum type to which the subDAG need to be promoted, and the second
pass then does all of the SDOperand promotions.

However, I'm starting to notice that I'm having to duplicate switch
statements or add nasty if/then statements having to do with which pass
is currently active. I am starting to think that these promotion
functions really ought to be SDOperand virtual methods. Why promote the
SDOperands when you can ask the SDOperands to promote themselves (*)?

How much objection would there be if I rolled for initiative and created
extra files, one per SDOperand subclass in a CodeGen subdirectory? At a
minimum the source for each SDOperand subclass would contain its
destructor, and would also get rid of all of those Anchor() virtual
functions.

I know there's been talk in the past of cleaning up the Legalize switch
statement, but, for the record, that's not my objective -- although this
would lay out some groundwork for that subproject to evolve, should it
ever materialize. I'm also not talking about splitting up the
SelectionDAGNodes.h header file. Just creating additional source file
hierarchy (yes, I can hear the groans about extra compilation overhead)
so that augmenting SDOperand and its children is less onerous.


-scooter

(*) MIT response to how different disciplines hunt elephants in Africa:
"Sociologists don't hunt elephants, they help elephants find themselves."