[PATCH] Address Space Casting

Eli Friedman eli.friedman at gmail.com
Thu Sep 5 16:49:19 PDT 2013


On Thu, Sep 5, 2013 at 3:56 PM, Michele Scandale <michele.scandale at gmail.com
> wrote:

> Il giorno 05/set/2013, alle ore 21:37, Eli Friedman <
> eli.friedman at gmail.com> ha scritto:
>
> On Thu, Sep 5, 2013 at 2:22 AM, Michele Scandale <
> michele.scandale at gmail.com> wrote:
>
>> On 09/05/2013 09:27 AM, David Chisnall wrote:
>> > On 4 Sep 2013, at 20:59, Eli Friedman <eli.friedman at gmail.com> wrote:
>> >
>> >> Or it could have been a ptrtoint+inttoptr pair originally, which would
>> get turned into a bitcast by instcombine.
>> >>
>> >> I don't see what's wrong with the choice of turning such a bitcast
>> back into a ptrtoint+inttoptr pair.
>> >
>> > Yes, that's probably the best approach.
>> >
>> > David
>> >
>>
>> Fine. Just a question: what integer size should I use? The target data
>> layout
>> information should not be available during the parsing of a Module, so I
>> do not
>> know what integer to use for the ptrtoint. Is it safe to assume that the
>> maximum
>> size is 64 bit?
>>
>>
> (BTW, the .ll parser doesn't need to auto-upgrade, only the .bc parser.)
>
>
> Why not? The auto upgrade mechanism isn't responsible for backward
> compatibility? Parsing an old file with a bitcast between pointer with
> different address space wild generate a parsing error (due to the
> additional check added in CastInst::castIsValid static method). Maybe I
> haven't understood correctly the auto upgrade mechanism.
>

We don't promise backward compatibility for .ll files, only .bc files.

-Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130905/292a0949/attachment.html>


More information about the llvm-commits mailing list