This is an archive of the discontinued LLVM Phabricator instance.

[Clang - ARM/AArch64] Add ACLE special register intrinsics (10.1)
ClosedPublic

Authored by LukeCheeseman on May 12 2015, 2:40 AM.

Details

Summary

This patch implements clang support for the ACLE special register intrinsics in section 10.1, __arm_{w,r}sr{,p,64}.

This includes arm_acle.h definitions with builtins and codegen to support these, the intrinsics are implemented by generating read/write_register calls which get appropriately lowered in the backend based on the register string provided. SemaChecking is also implemented to fault invalid parameters, however SemaChecking currently only supports checking in when the register string is in an encoded form, e.g. "cp1:2:c3:c4:5", that the encoding is valid. Otherwise, checking just assumes that the string is a special register value, e.g. "CPSR"; this means that if the register value passed is not a valid special register value, it passes checking and reports an error in the backend when attempting to lower the read/write_register intrinsic. I would like to have more checking on these values in the frontend to provide more useful diagnostics but couldn't think of a clean and nice way of doing it.

Diff Detail

Event Timeline

LukeCheeseman retitled this revision from to [Clang - ARM/AArch64] Add ACLE special register intrinsics (10.1).
LukeCheeseman updated this object.
LukeCheeseman edited the test plan for this revision. (Show Details)
LukeCheeseman added a subscriber: Unknown Object (MLST).
rengolin added inline comments.May 12 2015, 2:48 AM
lib/CodeGen/CGBuiltin.cpp
4285

This could be factored out into a static function together with the ARM counterpart above.

Re-factored the code for the AArch64 and ARM special registers builtins to a common helper function.

Updating patch for latests revision of sources.

rengolin added inline comments.May 28 2015, 6:44 AM
lib/CodeGen/CGBuiltin.cpp
3271

IsAArch64 in a generic function doesn't make sense. Is64Bit may make some sense, but I'd prefer if you pass what you really need.

In this case, I believe it's more about the types. So just receive what (input/output) types you need, and let the caller decide which types to pass.

4299

For example, you could use this boolean to create a type:

llvm::Type *Ty = (Is64Bit ? Int64Ty : Int32Ty);

and pass Ty, instead of the boolean.

lib/Sema/SemaChecking.cpp
2613

same argument here.

Removing IsAArch64 (and Is64Bit) from helper functions to make them more generic. Replacing these parameters with the types for the operation when generating IR. Passing through the BuiltinID for the SemaChecking.

rengolin accepted this revision.Jun 5 2015, 4:46 AM
rengolin added a reviewer: rengolin.

Hi Luke,

Thanks for the change, looks good to me, now. Feel free to commit with the nitpick changes.

cheers,
--renato

lib/CodeGen/CGBuiltin.cpp
3297

nitpick: this could be commoned up with the write version below:

bool MixedTypes = RegisterType->isIntegerTy(64) && ValueType->isIntegerTy(32);

Maybe we should assert that the other way around doesn't happen:

assert(!(RegisterType->isIntegerTy(32) && ValueType->isIntegerTy(64)) && "Can't fit 64-bit value in 32-bit register");
This revision is now accepted and ready to land.Jun 5 2015, 4:46 AM

Hi Renato,

Thanks for the suggestions, I will apply them right away. I have one concern with respect to the semantic checking however, currently if an invalid register string is passed to one of the intrinsics the semantic checking won't detect this and so will not provide the user with a diagnostic. Instead, the error will occur in the backend when the write_register or read_register is to be lowered but cannot be done so successfully and a fatal error will occur (through report_fatal_error). For example:

$ cat tmp.c
#include <arm_acle.h>

unsigned read_notareg() {
  return __arm_rsr("notareg");
}

$ clang tmp.c -target arm-none-none-eabi -S
fatal error: error in backend: Invalid register name "notareg".
(error and bug report)

Is this acceptable? I believe those kinds of errors are for invalid user input. I couldn't think of way to check the possible strings in the semantic checking that would avoid bringing most of the logic into the frontend and so was wondering if you had any suggestions on the matter.

Thanks,
Luke

Is this acceptable? I believe those kinds of errors are for invalid user input. I couldn't think of way to check the possible strings in the semantic checking that would avoid bringing most of the logic into the frontend and so was wondering if you had any suggestions on the matter.

Unfortunately, yes. There is currently no way of knowing what register names are available in Clang, which would need a Target Description that doesn't need all back-ends to be built (work in progress). For now, having that error in the back-end is the only way we can do, so it's acceptable.

cheers,
--renato

This revision was automatically updated to reflect the committed changes.