llvm dev - Mar 2015 - [LLVMdev] Moving towards a singular pointer type

Hi David,

On 18 Feb 2015, at 06:47, David Blaikie <dblaikie at gmail.com>
wrote:
> 
> 1) add explicit types where required in IR instructions - gep, load, byval,
anything else I can find...
>   a) Provide the mechanism to specify it (in textual IR, bitcode, and LLVM
IR APIs)
>   b) Update callers to Clang, LLVM, and Polly, to pass that information
(initially just asserting that it's the same information as was provided by
the typed-pointer operands)
Thank you very much for providing a script for updating the test cases.  This
was immensely valuable for updating our out-of-tree tests.

One thing that our update showed, however, was that the script did not work for
GEPs that had a non-zero address space pointer as the base.  Most of our tests
had at least one such GEP, but given that you didn't encounter this problem
it looks like there's a fairly substantial gap in test coverage in LLVM. 
People with in-tree targets that support multiple address spaces might want to
take a look at this omission...

David

On Thu, Mar 26, 2015 at 3:46 AM, David Chisnall <David.Chisnall at
cl.cam.ac.uk
> wrote:
> Hi David,
>
> On 18 Feb 2015, at 06:47, David Blaikie <dblaikie at gmail.com>
wrote:
> >
> > 1) add explicit types where required in IR instructions - gep, load,
> byval, anything else I can find...
> >   a) Provide the mechanism to specify it (in textual IR, bitcode, and
> LLVM IR APIs)
> >   b) Update callers to Clang, LLVM, and Polly, to pass that
information
> (initially just asserting that it's the same information as was
provided by
> the typed-pointer operands)
>
> Thank you very much for providing a script for updating the test cases.
> This was immensely valuable for updating our out-of-tree tests.
>
Great - I'm glad they worked out well.

> One thing that our update showed, however, was that the script did not
> work for GEPs that had a non-zero address space pointer as the base.

Hmm, that's curious - GEP operators or GEP instructions? I think I came
across non-zero address spaces in the base pointer type & had the scripts
cope with that in both cases (GEP operator and GEP instruction). Do you
have a specific example? I'd be happy to update the test script so that
it's improved in case anyone else hits this.

Here's one example from the gep instruction changes (none of the test cases
in that commit were updated manually, all were done using the script)

-  %arrayidx = getelementptr <2 x i32> addrspace(1)* %tmp, i32 %tmp1
+  %arrayidx = getelementptr <2 x i32>, <2 x i32> addrspace(1)*
%tmp, i32
%tmp1

Is there some other use of addrspace you're referring to/I'm not
understanding?


> Most of our tests had at least one such GEP, but given that you didn't
> encounter this problem it looks like there's a fairly substantial gap
in
> test coverage in LLVM.  People with in-tree targets that support multiple
> address spaces might want to take a look at this omission...
>
> David
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150327/72e2def9/attachment.html>

On 27 Mar 2015, at 15:47, David Blaikie <dblaikie at gmail.com>
wrote:
> 
> Here's one example from the gep instruction changes (none of the test
cases in that commit were updated manually, all were done using the script)
> 
> -  %arrayidx = getelementptr <2 x i32> addrspace(1)* %tmp, i32 %tmp1
> +  %arrayidx = getelementptr <2 x i32>, <2 x i32> addrspace(1)*
%tmp, i32 %tmp1
> 
> Is there some other use of addrspace you're referring to/I'm not
understanding?
That looks like the form that we were seeing, but it ended up being translated
with the addrspace(1) bit before the comma as well.

David