llvm dev - Jul 2019 - Typeless pointers and intrinsics

To avoid going too off-topic on the multidimensional gep thread, I'm asking
this in a separate thread.
>> I took a look earlier and didn't notice any target-independent ones
that would need a separate type parameter
Do you know what would happen  with the llvm.ptr.annotation intrinsic? Frontends
use that to annotate members of structs:

struct S {
   [[some_annotation]] int annotated_array[10];
   int not_annotated_array[100;
};

However, there is a big difference between annotating a pointer of type S*, a
pointer of type [10 x i32]*, and a pointer of type i8*.  The intrinsic is
overloaded for "any pointer"  type to allow distinguishing between
those three cases. Do you think we can represent this in a different way once
pointers become opaque?

-----Original Message-----
From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Tim
Northover via llvm-dev
Sent: Wednesday, July 24, 2019 4:14 PM
To: Michael Kruse <llvmdev at meinersbur.de>
Cc: LLVM Developers Mailing List <llvm-dev at lists.llvm.org>; Michael
Kruse <llvm at meinersbur.de>; SAHIL GIRISH YERAWAR <cs15btech11044 at
iith.ac.in>; Michael Ferguson <mferguson at cray.com>; Tobias Grosser
<tobias.grosser at inf.ethz.ch>
Subject: Re: [llvm-dev] [RFC] A new multidimensional array indexing intrinsic

Hi all,

On Wed, 24 Jul 2019 at 16:14, Michael Kruse via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> Mmmh, looks like Tim Northover is actively working on typeless/opaque 
> pointers, e.g. https://reviews.llvm.org/D64203
Yep, I'm spending as much time as I can on the project. I think there's
not really much chance that it'll be required in this cycle (i.e. when we
fork in ~Jan pointers will be distinct IMO).

On intrinsics as they affect opaque pointers, I took a look earlier and
didn't notice any target-independent ones that would need a separate type
parameter, but a couple of target-specific ones did.
Unless they were particularly anomalous and implementable by other means,
intrinsics will need to develop the ability to specify an abstract "notable
type" anyway.

Apart from all that, I'm pretty disappointed to see this as an intrinsic
though. GEP is such a fundamental part of addressing in LLVM that bifurcating it
into an intrinsic for either a language or an analysis seems like we'd be
papering over a language deficiency.

Cheers.

Tim.
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

On Thu, 25 Jul 2019 at 12:49, De Azevedo Piovezan, Felipe
<felipe.de.azevedo.piovezan at intel.com> wrote:
> >> I took a look earlier and didn't notice any target-independent
ones that would need a separate type parameter
>
> Do you know what would happen  with the llvm.ptr.annotation intrinsic?
Frontends use that to annotate members of structs:
>
> struct S {
>    [[some_annotation]] int annotated_array[10];
>    int not_annotated_array[100;
> };
>
> However, there is a big difference between annotating a pointer of type S*,
a pointer of type [10 x i32]*, and a pointer of type i8*.  The intrinsic is
overloaded for "any pointer"  type to allow distinguishing between
those three cases. Do you think we can represent this in a different way once
pointers become opaque?
I hadn't thought about that one specifically. I'm not entirely
convinced it merits special treatment if I'm honest: I can't imagine
we'd add an extra facility if we were designing the facility from
scratch in a world with opaque pointers; we'd probably just tell
people to mangle the type into the string somehow if it matters to
them since the whole point is to provide such a side channel anyway.

That said, I strongly suspect at least one intrinsic *will* need an
extra parameter, and once the machinery is in place applying it to
@llvm.ptr.annotate wouldn't be difficult if we do decide it's a good
idea.

Cheers.

Tim.

Hi,

Speaking of llvm.ptr.annotation intrinsic. From LLVM Lang ref:
  "This is an overloaded intrinsic. You can use ‘llvm.ptr.annotation’ on a
pointer to an integer of any width."

Also in Intrinsics.td ptr.annotation is defined with
LLVMAnyPointerType<llvm_anyint_ty>.

But in the same time I was able to generate the intrinsic with any other but
integer types, for example for union:
"@llvm.ptr.annotation.p0s_union._ZTS2un.uns(%union._ZTS2un.un , i8, i8*,
i32)". And verifier accepted this code!

So from what I see, it's a bug in verifier, that doesn't check for a
pointer type. But having typeless ptr.annotation intrinsic seems to be a very
useful feature, so does it make sense to make lang ref reflecting todays reality
instead of adding this missed type check?

-Dmitry Sidorov


-----Original Message-----
From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Tim
Northover via llvm-dev
Sent: Thursday, July 25, 2019 3:04 PM
To: De Azevedo Piovezan, Felipe <felipe.de.azevedo.piovezan at intel.com>
Cc: llvm-dev <llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] Typeless pointers and intrinsics

On Thu, 25 Jul 2019 at 12:49, De Azevedo Piovezan, Felipe
<felipe.de.azevedo.piovezan at intel.com> wrote:
> >> I took a look earlier and didn't notice any target-independent
ones
> >> that would need a separate type parameter
>
> Do you know what would happen  with the llvm.ptr.annotation intrinsic?
Frontends use that to annotate members of structs:
>
> struct S {
>    [[some_annotation]] int annotated_array[10];
>    int not_annotated_array[100;
> };
>
> However, there is a big difference between annotating a pointer of type S*,
a pointer of type [10 x i32]*, and a pointer of type i8*.  The intrinsic is
overloaded for "any pointer"  type to allow distinguishing between
those three cases. Do you think we can represent this in a different way once
pointers become opaque?
I hadn't thought about that one specifically. I'm not entirely convinced
it merits special treatment if I'm honest: I can't imagine we'd add
an extra facility if we were designing the facility from scratch in a world with
opaque pointers; we'd probably just tell people to mangle the type into the
string somehow if it matters to them since the whole point is to provide such a
side channel anyway.

That said, I strongly suspect at least one intrinsic *will* need an extra
parameter, and once the machinery is in place applying it to @llvm.ptr.annotate
wouldn't be difficult if we do decide it's a good idea.

Cheers.

Tim.
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

--------------------------------------------------------------------
Joint Stock Company Intel A/O
Registered legal address: Krylatsky Hills Business Park,
17 Krylatskaya Str., Bldg 4, Moscow 121614,
Russian Federation

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.