[LLVMdev] Area for improvement

[Vikram S. Adve]

> The second issue is that we need to do redundancy elimination and 
> hoisting on operations that are only exposed once instruction 
> selection is performed.  Getelementptr expansion is just ONE 
> particular case of this, but it can happen with any instructions 
> (including the use of large integer (or any FP) constants on RISC 
> machines, addressing globals with PIC code, handling 
> extended/truncated operations (for RISC machines with a single integer 
> size), etc.  Note that hacks like "LowerMultiDimRefs" and the sparc 
> Preselection pass sorta-kinda work around SOME of this,

Actually, they are capable of working around much of this, and most 
such optimizations are actually quite architecture-independent, e.g., 
LowerMultiDimRefs, which is a major optimization for array-intensive 
languages.

I don't claim such choices are the right long-term solution but the 
right long-term solution is exactly what you're implying below - a new 
optimization framework within the back-end, working on it's own 
representation, etc.  This has taken 4 years and is still under 
development.  This is why what you call "hacks" are sometimes the right 
choice in the short term.


> The only way to make preselection or lowermultidimrefs work is to 
> duplication all of the knowledge of how the instruction selector will 
> select the code (e.g. the advice about allowing constant indices to be 
> grouped together).

This is why you need a separate, low-level optimization framework - the 
kind you were describing.

--Vikram
http://www.cs.uiuc.edu/~vadve
http://llvm.cs.uiuc.edu/