This is an archive of the discontinued LLVM Phabricator instance.

[ARM64] Correct more bounds checks/diagnostics for arithmetic shift operands
ClosedPublic

Authored by bsmith on May 9 2014, 7:20 AM.

Details

Summary

Patch to correct more bounds checks/diagnostics for arithmetic shift operands, this also make various invalid shifts actually invalid hence some test updates were needed.

As with my previous patches, there is no testcase for this as it is part of the merge of MC/AArch64/basic-a64-diagnostics.s.

Diff Detail

Event Timeline

bsmith updated this revision to Diff 9259.May 9 2014, 7:20 AM
bsmith retitled this revision from to [ARM64] Correct more bounds checks/diagnostics for arithmetic shift operands.
bsmith updated this object.
bsmith edited the test plan for this revision. (Show Details)
bsmith added a reviewer: t.p.northover.
bsmith set the repository for this revision to rL LLVM.
bsmith added a subscriber: Unknown Object (MLST).
t.p.northover edited edge metadata.May 9 2014, 11:16 AM

Hi Bradley,

I've got one question about this one:

lib/Target/ARM64/AsmParser/ARM64AsmParser.cpp
2476–2478

What goes wrong if we just add the shift and let the isXYZ methods take care of it? It seems like it might be more consistent way to handle things in general.

bsmith added inline comments.May 12 2014, 2:09 AM
lib/Target/ARM64/AsmParser/ARM64AsmParser.cpp
2476–2478

The shifts are encoded into a single integer in such a way that 0x3f is the maximum value for the shift, if you add one that exceeds this then it overflows into the shift type field in such a way that can turn it into a different valid shift type, if it doesn't assert first.

To be honest, I'm not sure why shifts/extracts/other things are encoded into a single integer like this, rather than using separate operand fields as AArch64 does, it seems to only cause headaches.

The shifts are encoded into a single integer in such a way that 0x3f is the maximum value for the shift, if you add one that exceeds this then it overflows into the shift type field in such a way that can turn it into a different valid shift type, if it doesn't assert first.

OK, that makes sense for now. You should probably commit this one as
it is then, and we'll handle that combined operand separately.

Cheers.

Tim.

bsmith accepted this revision.May 12 2014, 2:49 AM
bsmith added a reviewer: bsmith.
This revision is now accepted and ready to land.May 12 2014, 2:49 AM
bsmith closed this revision.May 12 2014, 2:49 AM