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