[llvm-dev] LTO and intrinsics mangling

[Philip Reames via llvm-dev]

On 04/19/2016 09:35 AM, Ahmed Bougacha wrote:
> 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.").
Er, not sure what you're getting at.  The value type has to match the 
pointee type of the address type.  If we can't have a value type which 
is a struct, how'd we end up with a struct typed pointer?
>
> And since the backend only distinguishes pointer types based on
> addresspace, pNi8 seems sufficient, no?
>
> -Ahmed