[LLVMdev] Recent Commits by Tim Northover

[Tim Northover]

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).

> 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.