This is an archive of the discontinued LLVM Phabricator instance.

Add aliases for VAND imm to VBIC ~imm
ClosedPublic

Authored by rengolin on Sep 9 2014, 5:13 AM.

Details

Summary

On ARM NEON, VAND with immediate (16/32 bits) is an alias to VBIC ~imm with
the same type size. Adding that logic to the parser, and generating VBIC
instructions from VAND asm files.

Fixes PR20702.

Diff Detail

Event Timeline

rengolin updated this revision to Diff 13453.Sep 9 2014, 5:13 AM
rengolin retitled this revision from to Add aliases for VAND imm to VBIC ~imm.
rengolin updated this object.
rengolin edited the test plan for this revision. (Show Details)
rengolin added reviewers: t.p.northover, jmolloy.
rengolin set the repository for this revision to rL LLVM.
rengolin added a subscriber: Unknown Object (MLST).
t.p.northover edited edge metadata.Sep 9 2014, 5:36 AM

Hi Renato,

Have a razor, I think you've got a yak to shave...

lib/Target/ARM/ARMInstrNEON.td
39

PrintMethod shouldn't be needed since the aliases aren't canonical.

lib/Target/ARM/AsmParser/ARMAsmParser.cpp
1629

Is this right? From the ARM ARM it looks like the set of constants permitted is not invariant under Imm -> ~Imm.

Actually, the code above in isNEONi16Splat is wrong too (which is why your test happens to work anyway):

$ echo "vbic.i16 d10, #0x03ff" | bin/llvm-mc -triple armv7 -show-inst
    vbic.i16 d10, #0x300
2409

This isn't really a validation (which implies it might be invalid). Perhaps an "encodeNEON..."; if so, it should probably go into MCTargetDesc with the others.

rengolin added inline comments.Sep 9 2014, 6:27 AM
lib/Target/ARM/ARMInstrNEON.td
39

ok

lib/Target/ARM/AsmParser/ARMAsmParser.cpp
1629

Oh god, no! Lazy arse, I am. I meant to invert the value first, but got too excited that my test case passed! Sorry.

2409

encode is a better name, yes. Where in MCTargetDesc you're thinking of?

t.p.northover added inline comments.Sep 9 2014, 6:30 AM
lib/Target/ARM/AsmParser/ARMAsmParser.cpp
2409

It looks like there's already some utilities for modified NEON values in ARMAddressingModes.h. Just no encode that I could see yet.

rengolin updated this revision to Diff 13462.Sep 9 2014, 7:32 AM
rengolin edited edge metadata.

Right, ignoring the code in isNEONi32splat() for now, I just want to make sure everything is in the right place.

I have:

  • removed the unnecessary print methods
  • moved validateNEON... to ARMAddressingModes.h as encodeNEON...
  • added a common isNEON to the same header and inverted the value on ...SplatNot methods

I haven't:

  • fixed isNEON...
  • added enough tests to make sure a whole range of values are encoded correctly

I don't know if:

  • isNEON... is a good name, since that it's now just checking for splat consistency and changing it. Maybe encodeNEON...Value() would be better?

Hi Renato,

The names look reasonable. About the one thing I'd change is not mentioning "Operands" in ARMAddressingModes.h. That's entirely a bike-shedding point though, I wouldn't have mentioned it if you hadn't specifically mentioned names as something you weren't sure of.

Cheers.

Tim.

lib/Target/ARM/AsmParser/ARMAsmParser.cpp
1653–1654

Is this right? I don't know what it's trying to exclude for VBIC, but I'd be slightly surprised if just these 4 aliases also make it work for VAND too.

2434–2435

It'd be nice if there was some consistency between the i16 and i32 variants here (int/int64_t/unsigned/...). It feels like there ought to be a good canonical representation.

lib/Target/ARM/MCTargetDesc/ARMAddressingModes.h
581

assert on low bits here, when you get around to fixing the bug?

Thanks for the review, Tim. I'll refactor the names and types and start working on the acceptable cases and errors.

cheers,
--renato

lib/Target/ARM/AsmParser/ARMAsmParser.cpp
1653–1654

Honestly, I don't know. Until now, it was more like copy&paste than anything else. I'll start paying attention to the edge cases when the names and locations are correct and some of the cases can be dealt with, so it becomes easier to debug and trace the paths.

2434–2435

The reason why one is unsigned and the other is uint64_t is because on the 32-bit case, there's a warning on a comparison with the sign bit in isNEONi32splat. I'll see if I can make it less confusing...

rengolin updated this revision to Diff 13559.Sep 10 2014, 2:12 PM

Many changes since last diff...

  • fixed immediate checking
  • renamed functions to be consistent
  • made all arguments unsigned int
  • added more tests for valid and invalid patterns

I believe now it's a lot closer to committing quality.

aadg added a subscriber: aadg.Sep 25 2014, 3:15 AM

Looks good to me.

aadg added a comment.Sep 25 2014, 4:08 AM

This look ok to me.

For some reason, the comment I made in phabricator never made it to the mailing list.

Cheers,

Arnaud

From: mankeyrabbit@gmail.com [mailto:mankeyrabbit@gmail.com] On Behalf Of James Molloy
Sent: 25 September 2014 09:41
To: reviews+D5263+public+da960b6b095f8b86@reviews.llvm.org
Cc: James Molloy; LLVM Commits; Tim Northover; Arnaud De Grandmaison
Subject: Re: [PATCH] Add aliases for VAND imm to VBIC ~imm

Adding Arnaud as he is working on pseudo instructions.

Thanks Arnaud, I got the email... :)

rengolin accepted this revision.Sep 25 2014, 4:41 AM
rengolin added a reviewer: rengolin.

Committed in r218450.

Thanks!
--renato

This revision is now accepted and ready to land.Sep 25 2014, 4:41 AM
rengolin closed this revision.Sep 25 2014, 4:41 AM