search for: pr37682

...is the final output of the compiler, IMHO richer metadata > should be used in the meantime. > > IMHO the implicit pointer work doesn't need to block on this. As said > my mild preference would be for a new intrinsic for this form of > variable location. > > ~ > > Inre PR37682, > > > I’ve been reminded of PR37682, where a function with a reference > parameter might spend all its time computing the “referenced” value in a > temp, and only move the final value back to the referenced object at the > end. This is clearly a situation that could benefit from...

> I don't have a strong opinion on representation. I can see how having a dedicated instruction to model implicit pointers would aid readability & be simpler to document/grok, but perhaps in the future we'll want to support other operations that refer to variable > DIEs. In the short term migrating to an extended dbg.value representation might take more work. Alok, wdyt? Below

FWIW, I've raised the LICM issue here: https://bugs.llvm.org/show_bug.cgi?id=37682 On 31 May 2018 at 13:28, Anast Gramm <anastasis.gramm2 at gmail.com> wrote: > Thanks, > These are very helpful. > > As I understand it, SROA and LICM render some variables > "useless" by optimizing the code to not use them. Hence we can't debug > them. > >

...>> IMHO the implicit pointer work doesn't need to block on this. As said >>>>> my mild preference would be for a new intrinsic for this form of >>>>> variable location. >>>>> >>>>> ~ >>>>> >>>>> Inre PR37682, >>>>> >>>>> > I’ve been reminded of PR37682, where a function with a reference >>>>> parameter might spend all its time computing the “referenced” value in a >>>>> temp, and only move the final value back to the referenced object at th...

...hould be used in the meantime. >>> >>> IMHO the implicit pointer work doesn't need to block on this. As said >>> my mild preference would be for a new intrinsic for this form of >>> variable location. >>> >>> ~ >>> >>> Inre PR37682, >>> >>> > I’ve been reminded of PR37682, where a function with a reference >>> parameter might spend all its time computing the “referenced” value in a >>> temp, and only move the final value back to the referenced object at the >>> end. This is cle...

...gt; my mild preference would be for a new intrinsic for this form of >>>>>>>>>> variable location. >>>>>>>>>> >>>>>>>>>> ~ >>>>>>>>>> >>>>>>>>>> Inre PR37682, >>>>>>>>>> >>>>>>>>>> > I’ve been reminded of PR37682, where a function with a >>>>>>>>>> reference parameter might spend all its time computing the “referenced” >>>>>>>>>> va...

On Fri, Nov 15, 2019 at 8:07 AM Robinson, Paul <paul.robinson at sony.com> wrote: > | Any ideas why it wouldn't be more general to handle cases where the > variable isn't named? > > > > Couldn’t there be a DIE (flagged as artificial) to describe the > return-value temp? > There could be - though there are very few (the array bound example Adrian gave is the