Page MenuHomePhabricator

[AArch64] Introduce features that will allow only assembler support for neon, crypto, fp-armv8 and fullfp16.
Needs ReviewPublic

Authored by sbaranga on Nov 18 2016, 7:58 AM.

Details

Summary

The purpose of these features is to allow us to change the
behaviour of the -mgeneral-regs-only option to match
the gcc behavior (restrict code generation but not add
constraints for the assembler).

Fixes https://llvm.org/bugs/show_bug.cgi?id=30792

Event Timeline

sbaranga updated this revision to Diff 78529.Nov 18 2016, 7:58 AM
sbaranga retitled this revision from to [AArch64] Introduce features that will allow only assembler support for neon, crypto, fp-armv8 and fullfp16..
sbaranga updated this object.
sbaranga added a subscriber: llvm-commits.

This option seems like a near duplicate for -mno-implicit-float in the backend, which already works in this configuration. It differs over what happens if explicit floats are used, but we seem to produce thoroughly unsupported soft-float code at the moment, so that probably doesn't matter.

So I'd suggest changing how Clang treats -mgeneral-regs-only to match -mno-implicit-float. Then maybe deciding what that should do if someone actually uses floats.

Tim. (Also commented on bug along similar lines).

Thanks, that makes sense. I also wasn't aware of no-implicit-float.

If gcc rejects floating point uses we should probably do the same, but it's not exactly clear to me what the rules are for rejecting these uses.
For example it seems that declaring a global float is ok, and it is also fine to write "int a(float t);", so I think we need to only reject the uses inside a function body?

What about explicit uses of vector types? Would that be solved because the user wouldn't be able to include arm_neon.h?

-Silviu

If gcc rejects floating point uses we should probably do the same

Possibly, the error message rather suggests that's not the desired behaviour though:

tmp.c:2:7: sorry, unimplemented: ‘-mgeneral-regs-only’ and floating point code

It's not even got "error:". Might be worth having a chat with Marcus or Richard on the GCC side to see if they have some long-term behaviour in mind.

What about explicit uses of vector types? Would that be solved because the user wouldn't be able to include arm_neon.h?

I think we support the vector attributes independently of arm_neon.h so they should probably be disallowed too.

It looks like gcc should have been emitting an error here instead of the "sorry, not implemented".

fhahn edited edge metadata.Dec 20 2016, 2:38 AM
fhahn added a subscriber: fhahn.