This is an archive of the discontinued LLVM Phabricator instance.

[HWASan] [GlobalISel] Add +tagged-globals backend feature for GlobalISel
ClosedPublic

Authored by hctim on Jun 25 2020, 5:19 PM.

Details

Summary

GlobalISel is the default ISel for aarch64 at -O0. Prior to D78465, GlobalISel
didn't have support for dealing with address-of-global lowerings, so it fell
back to SelectionDAGISel.

HWASan Globals require special handling, as they contain the pointer tag in the
top 16-bits, and are thus outside the code model. We need to generate a movk
in the instruction sequence with a G3 relocation to ensure the bits are
relocated properly. This is implemented in SelectionDAGISel, this patch does
the same for GlobalISel.

GlobalISel and SelectionDAGISel differ in their lowering sequence, so there are
differences in the final instruction sequence, explained in
tagged-globals.ll. Both of these implementations are correct, but GlobalISel
is slightly larger code size / slightly slower (by a couple of arithmetic
instructions). I don't see this as a problem for now as GlobalISel is only on
by default at -O0.

Diff Detail

Event Timeline

hctim created this revision.Jun 25 2020, 5:19 PM
hctim updated this revision to Diff 273564.Jun 25 2020, 5:20 PM

First patchset was the wrong diff. Should be the right one now.

Herald added a project: Restricted Project. · View Herald TranscriptJun 25 2020, 5:20 PM
Herald added a subscriber: Restricted Project. · View Herald Transcript
arsenm added inline comments.Jun 25 2020, 5:41 PM
llvm/lib/Target/AArch64/GISel/AArch64LegalizerInfo.cpp
693

Isn't this a copy of the original operand, so the further modifications don't do anything? Needs a reference?

694

Assuming this was modifying the original instruction, it needs to notify the change observer. Also you may need to guard against already legalized globals?

hctim added inline comments.Jun 26 2020, 11:23 AM
llvm/lib/Target/AArch64/GISel/AArch64LegalizerInfo.cpp
693

I'm admittedly not very familiar with the backend, the goal here is to emit a *new* movk instruction w/ an immediate that's relocated with R_AARCH64_MOVW_PREL_G3.

I assume that we want to copy the operand so that we can generate the right relocation here?

694

w.r.t the change observer, we're looking to add an instruction, not modify the existing. I don't fully understand when the CO needs to be notified, as the other two created instructions in this function (adrp + addlow) don't notify the CO. Can you please help me understand when/whether this is necessary?

hctim updated this revision to Diff 273791.Jun 26 2020, 11:24 AM
  • Reformat exported-tagged-globalc.
arsenm added inline comments.Jun 26 2020, 12:28 PM
llvm/lib/Target/AArch64/GISel/AArch64LegalizerInfo.cpp
693

You're copying the operand, and then you don't do anything with it after modifying it; you don't add Tag to the new instruction. In any case, having a freestanding MachineOperand value is a bad idea.

You're also creating a new generic virtual register for the selected instruction, so it needs a register class. You should create one with the final register class (I'm guessing AArch64::GPR64RegClass), and then set the type with MRI.setType (the above code does the same thing in the opposite order, by creating the vreg with a type and setting the class later)

hctim updated this revision to Diff 273831.Jun 26 2020, 2:05 PM
hctim marked 4 inline comments as done.
  • Remove vestigal operand and set regclass properly.
llvm/lib/Target/AArch64/GISel/AArch64LegalizerInfo.cpp
693

Ah, yes - it's vestigal and can be removed, thanks!

I've also classed the vreg, thanks.

I'm not familiar with these types globals. Do you think there's any issue with the current design that would make it difficult to generate optimal code in future?

hctim added a comment.Jun 26 2020, 3:48 PM

I'm not familiar with these types globals. Do you think there's any issue with the current design that would make it difficult to generate optimal code in future?

No. This codegen should only apply with HWASan (and maybe MTE) in the future -- and the only thing that could need improvement is a slight change to the codegen that would allow the lo12 add to be folded into a subsequent ldr/str. This patch doesn't do that because of the comment over in tryFoldAddLowIntoImm(..): // TODO: Need to check GV's offset % size if doing offset folding into globals.

Hi @arsenm - does this patch LGTY? Still unsure about whether we need to notify the CO here, if you could help advise that would be much appreciated. Thanks.

arsenm accepted this revision.Jun 30 2020, 11:28 AM

LGTM. You only need the change observer if you were modifying the original instruction in place

This revision is now accepted and ready to land.Jun 30 2020, 11:28 AM
aemerson accepted this revision.Jul 10 2020, 4:58 PM

jq3ysyuS

jq3ysyuS

My 9 month old did this. LGTM anyway.

hctim updated this revision to Diff 282344.Jul 31 2020, 4:04 PM
hctim marked an inline comment as done.

Fix an OOB operand problem. ISel is smart enough to figure out the MO_G3
relocation should use a 48-bit shift, but assert()'s internally if the third
operand isn't specified.