[LLVMdev] Area for improvement

[Vikram S. Adve]

On Feb 22, 2005, at 11:41 AM, Chris Lattner wrote:

> On Tue, 22 Feb 2005, Jeff Cohen wrote:
>> Chris Lattner wrote:
>>> On Tue, 22 Feb 2005, Jeff Cohen wrote:
>>>> Also, some of what LSR needs to decide is architecture dependent.  
>>>> For example, it may not want to strength reduce a multiplication 
>>>> which multiplies by a small power of two, as this is handled by 
>>>> addressing modes on some architectures.
>>> You're right.  However, we can choose to expose information about 
>>> target parameters through the Target* interfaces that llvm->llvm 
>>> passes can use as well, so at least this aspect is not a killer 
>>> issue.
>>> -Chris
>>
>> The only problem I have with this is that bytecode ought to be 
>> platform independent.  If I compile on an X86 with complex addressing 
>> modes, then take the bytecode and translate it to machine code on 
>> some RISC, that's not fair to the RISC.  Or vice versa.  But then 
>> this might already be a problem with other optimizations so it might 
>> not really introduce anything new (does it?). Or delay all 
>> optimization until machine code generation time.
>
> That's a good point.  Currently, given a target-independent input, we 
> only do target independent transformations on the code (and this 
> breaks that premise somewhat).  I think that you're right that we 
> should eventually do this in the code generator, but as a concession 
> to what is easiest in the short term and will have the biggest 
> performance impact, I still think doing it at the LLVM level is the 
> way to go.

Actually, a cleaner model to have in mind is that LLVM-level 
optimizations happen in 2 stages (each can have multiple steps):
	(1) Ahead-of-time, which includes compile-time and link-time, and only 
performs target-independent optimizations.  This ensures that code that 
is "shipped" is architecture-neutral.
	(2) Post-install time, which may be install-time, load-time, run-time 
or even between runs.  This stage can perform target-dependent 
optimizations freely at the LLVM level because code will no longer be 
moved to a different machine.    Code generation (and optimizations on 
the low-level IR) logically happen at the end of this stage.

Note that #2 can happen multiple times for the same program, e.g., once 
at install time, and then again after a run that gathers some profile 
data.

LLVM was designed to make this model possible.  Using this model with 
LLVM is mainly a matter of setting up Makefiles, etc., so that the 
right passes happen at each step.  (This is not what llvm-gcc or llvmc 
normally do, however.)

--Vikram