[llvm-dev] LTO and intrinsics mangling
Ahmed Bougacha via llvm-dev
llvm-dev at lists.llvm.org
Tue Apr 19 09:35:23 PDT 2016
On Mon, Apr 18, 2016 at 4:28 PM, Philip Reames
<listmail at philipreames.com> wrote:
>
>
>
> On 04/18/2016 10:52 AM, Ahmed Bougacha via llvm-dev wrote:
>
> On Mon, Apr 18, 2016 at 9:45 AM, Artur Pilipenko via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> > Does this sound reasonable? Are there any other alternatives?
>
> Would demoting pointer types to pNi8 work?
>
> As you say, that could potentially mask problems, but I don't think the type of the masked load/store matters, only the types of the pointer elements at the subsequent loads/stores.
> In other words, this sounds equivalent to opaque pointer types to me. A pointer load shouldn't care about the type.
>
> I went down this path too. It doesn't work unfortunately. The problem is that the value type of the store is also part of the signature and could be a struct type. Analogously, the same problem exists for the return type of the load. We can and do lower loads/stores of different value types differently. Memory isn't typed, but the operation is.
You're right, but I don't think that applies to masked load/stores, as
the value type can't be a struct type, it can only be a pointer to
struct type (langref says "The loaded data is a vector of any integer,
floating point or pointer data type.").
And since the backend only distinguishes pointer types based on
addresspace, pNi8 seems sufficient, no?
-Ahmed
More information about the llvm-dev
mailing list