[LLVMdev] Moving towards a singular pointer type

David Blaikie dblaikie at gmail.com
Fri Mar 27 08:47:32 PDT 2015

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
> >   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

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

> 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>

More information about the llvm-dev mailing list