[llvm-dev] The bit pattern after stripPointerCasts()

Philip Reames via llvm-dev llvm-dev at lists.llvm.org
Mon Dec 17 17:20:14 PST 2018


+1 to having both modes, well, if you find a case which is correct for 
the as-cast traversing one at least.

The default should probably be the non-as-cast traversing one for 
correctness.

Philip


On 12/14/18 9:04 AM, Doerfert, Johannes Rudolf via llvm-dev wrote:
> On 12/14, Matt Arsenault via llvm-dev wrote:
>>> On Dec 14, 2018, at 2:44 PM, Finkel, Hal J. <hfinkel at anl.gov> wrote:
>>>
>>> Do you have an opinion on which should be the default?
>>>
>>>   -Hal
>>>
>>>
>> Not particularly. The current name sounds to me like it would strip
>> any casts it possibly can. Maybe most uses should now be converted to
>> a newly named stripTrivialPointerCasts?
>>
>> -Matt
> I can certainly introduce a new stripTrivialPointerCasts() function that
> will keep the bit pattern while stripping casts. Wrt to the options I
> pointed out earlier (see below), this would then be 2). Afterwards, we
> might want to go through all the stripPointerCasts() users to make sure
> they do not actually want to call stripTrivialPointerCasts() instead.
>
>
> 1) Make stripPointerCasts not look through address space casts. A new
> function (or parameter) would then be introduced to do the same thing
> _and_ peel of address space casts.
>
> 2) Keep looking through address space casts in stripPointerCasts. A new
> function (or parameter) would then be introduced to do the same but with
> the guarantee that the bit pattern is preserved.
>
>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181217/d3cdfc16/attachment.html>


More information about the llvm-dev mailing list