Matt Arsenault via llvm-dev
2018-Dec-14 06:11 UTC
[llvm-dev] The bit pattern after stripPointerCasts()
> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181214/1699d4fb/attachment.html>
Doerfert, Johannes Rudolf via llvm-dev
2018-Dec-14 17:04 UTC
[llvm-dev] The bit pattern after stripPointerCasts()
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? > > -MattI 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-- Johannes Doerfert Researcher Argonne National Laboratory Lemont, IL 60439, USA jdoerfert at anl.gov -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181214/be93ea78/attachment.sig>
Philip Reames via llvm-dev
2018-Dec-18 01:20 UTC
[llvm-dev] The bit pattern after stripPointerCasts()
+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>