[LLVMdev] Recent Commits by Tim Northover

[Jim Grosbach]

On Dec 3, 2013, at 11:42 PM, Tim Northover <t.p.northover at gmail.com> wrote:

> Hi Gary,
> 
> On 3 December 2013 22:01, Gary Fuehrer <gfuehrer at defiant-tech.com> wrote:
>> The subject of two of his commits dealt with substituting MOVW/MOVT pairs
>> for an LDR and a lit-pool. Isn't this what MachineConstantPool and
>> ARMConstantIslandPass was all about?
> 
> Both are essential components to using lit-pools: the
> MachineConstantPool is just LLVM's underlying machinery and
> ARMConstantIslands is for fixing up out of range loads and so on so
> they can actually be used.
> 
> My recent changes have been to fix Darwin CodeGen so that they're
> actually useful (previously we combined movw/movt pairs referring to
> the same global but not litpool ones, which meant that litpools
> actually took up more room), and to enable them in "-Oz" mode.
> 
> It sounds like you're on an ELF platform, in which case (fingers
> crossed) you already get the combining unless you compile with
> "-fPIC". The "-Oz" change *should* just apply directly and be useful.
> Please let me know if it doesn't, I'd like to get the same benefits on
> ELF if at all possible.
> 
>> I vaguely recall a while back that it was disabled [...] What about enabling it again?
> 
> The only matching situation I can think of there is that Jim suggested
> I use a different approach for constants on 64-bit AArch64. I don't
> know the performance numbers, but frankly I was glad to kill it. The
> ConstantIslands pass is complicated enough that it *really* needs to
> justify itself and I don't think code size is a priority on AArch64.
> 
> It's still present, supported and enabled in 32-bit ARM, though until
> today only used for targets that didn't have movw/movt available (and
> perhaps some odd corner cases like floating constants).

It’s still enabled and used for all 32 bit targets, actually. Just not as aggressively. Consider 64 and 128 bit floating point and vector constants, for example.

> 
>> Islands are not being placed within range of a near LDR. They only appear
>> between functions. (It seemed to me like ARMConstanIslandPass was not
>> being used to make them.)
> 
> That's a very worrying bug, and shouldn't be happening at all. Do you
> have a .ll test-case you can show us?
> 
>> Finally, I would really like to see
>> this optimization be promoted from -Oz to -Os. Doesn't it satisfy the
>> criteria for -Os over -Oz?
> 
> Not generally, since in LLVM -Os means roughly "don't bloat code
> speculatively while looking for performance". On A-class cores,
> litpools are almost always slower so they don't qualify. We *could*
> enable it at -Os on M-class CPUs separately, but not without benchmark
> evidence (and I suspect it would have a bad effect even there).
> 
>> Tim's other commit was about stack adjustment folding. So, Tim, did you see
>> the treads with Andrea Mucignat back in October?
> 
> It rings some bells, but I wasn't paying much attention. I think she
> did get knowledgeable help; nothing in the thread jumps out as wrong.
> It looks like a reasonable goal, but as Renato said, should be
> considered carefully. It's a nasty area of the compiler and has
> knock-on effects.
> 
> Cheers.
> 
> Tim.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev