This is an archive of the discontinued LLVM Phabricator instance.

[ARM] Fix correctness checks in promoteToConstantPool.
ClosedPublic

Authored by efriedma on Aug 29 2018, 6:36 PM.

Details

Summary

Correctly check for relocations in the constant to promote. And don't allow promoting a constant multiple times.

This partially fixes https://bugs.llvm.org/show_bug.cgi?id=32780 ; it's not a complete fix because we also need to prevent ARMConstantIslands from cloning the constant.

(-arm-promote-constant is currently off by default, and it stays off with this patch. I'll look into turning it on again when all the known issues are fixed.)

Diff Detail

Repository
rL LLVM

Event Timeline

efriedma created this revision.Aug 29 2018, 6:36 PM
dmgreen added a subscriber: dmgreen.Sep 6 2018, 1:47 PM

Hello. Good to see this getting some love.

Sorry for the delay. I wanted to get D51410 in and see check what affect these had on performance. (And I've been busy with the regressions we've had come in lately). Results look good, although there's still some 16 byte alignment cases I need to look into.

Did you ever see D36787? It's almost certainly not worth looking at very much. I remember it being a bit over-complicated with constant pool entries pointing to other constant pool entries. If it helps, feel free to take what might be useful. I'm kind of hoping there is a better way than that though.

I will try and stare more closely at this tomorrow, if noone else takes a look earlier.

Did you ever see D36787? It's almost certainly not worth looking at very much. I remember it being a bit over-complicated with constant pool entries pointing to other constant pool entries. If it helps, feel free to take what might be useful. I'm kind of hoping there is a better way than that though.

No, I don't think I ever saw it (or at least, I don't remember seeing it).

Looking at it, yes, it does seem a little more complicated than I would have hoped for. But I'm not sure what a better solution would look like... I mean, if there are multiple tLEApcrel instructions referring to a given constant, ARMConstantIslands will be forced to do something like D36787 in general. (By "like D36787", I mean computing the address of the constant using some sequence that isn't a tLEApcrel; I guess instead of computing the address like the address of a global, you could "outline" the computation, but that's equally awkward).

I guess the alternative is to avoid cloning. If, in isel, we can prove that all references to the constant in question are lowered to a single SelectionDAG node (essentially, all references are in the same BasicBlock), we could lower that to some special tLEApcrel_nodup that's marked isNotDuplicable, and then ARMConstantIslands will ensure it's in range without cloning.

dmgreen accepted this revision.Sep 7 2018, 11:31 AM

Constant Island pass has a bit of a reputation for being the source of difficult bugs. With enough Mir testing, perhaps that doesn't need to be the case though. The general idea of turning the adr's into ldr's seems like a good one, maybe it just needs some better machinary in the pass to handle the pool entries more easily?

This here looks like two separate changes, both of which look fine to me.

This revision is now accepted and ready to land.Sep 7 2018, 11:31 AM
This revision was automatically updated to reflect the committed changes.