[PATCH] Address Space Casting

[Michele Scandale]

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.

> Do we really not have a data layout available at the point you need it? If we don't (or if the module doesn't have a data layout specified), just assuming 64 bits is fine.
> 

I'll investigate again to see if there a way to have access to target fatally out info.

Thanks in advance.

Best regards,
-Michele
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130906/3c95b19a/attachment.html>