arsenm added inline comments.
================ Comment at: llvm/include/llvm/IR/Intrinsics.td:903-907 +// Load of a value provided by the system library at a fixed address. Used for +// accessing things like HWCAP word provided by GLIBC. +def int_fixed_addr_ld + : DefaultAttrsIntrinsic<[llvm_i32_ty], [llvm_i32_ty], + [IntrInaccessibleMemOnly, ImmArg<ArgIndex<0>>]>; ---------------- nemanjai wrote: > arsenm wrote: > > nemanjai wrote: > > > arsenm wrote: > > > > From this description I don't understand what this is supposed to do. > > > > What does the input mean? Why does this use an i32 immarg and not a > > > > pointer? Why is the result only i32? > > > That is fair enough. The description is fairly vague. I can try to > > > improve it as per below. The parameter for this is not a pointer (i.e. > > > not an address). It is an immediate that represents the index into the > > > enumeration of values that are provided at a fixed address. The back end > > > is then free to produce the actual fixed address and the load itself. > > > The choice for the result type was admittedly arbitrary - on PPC, the > > > values provided by GLIBC are 32-bit words. > > > > > > Proposed comment describing this intrinsic: > > > ``` > > > // This intrinsic is provided to allow back ends to emit load > > > // instructions that load a value from a fixed address. The > > > // parameter to the intrinsic is not an address, but an > > > // immediate index into an enumeration that contains the > > > // union of all such values available on all back ends. > > > // An example is the HWCAP/HWCAP2/CPUID words > > > // provided by GLIBC on PowerPC to allow fast access > > > // to commonly used parts of AUXV. These are provided > > > // at a fixed offset into the TCB (accessible through the > > > // thread pointer). > > > ``` > > This is baking an a very target specific implementation of device > > identification. Could you redefine this as something more abstract? Like > > returns a device ID integer, or a bool that some int input is supported? > The idea is for this to not be restricted to device ID at all, but to be used > for any values that reside in a fixed address for the compiler. For example, > `STACK_GUARD` can be one of the values. How about if the intrinsic returns > any integer type (or maybe any type)? > My thinking is that there may be need in the future for various things to be > loaded from fixed addresses. The list of possible things that can be loaded > this way would be a union of what all targets want and only specific values > would make sense on each target. But you're assuming there's a fixed address this can be loaded from, and not a read from a special register or some other mechanism Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D152914/new/ https://reviews.llvm.org/D152914 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
