<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">At least in the case of MachineInstr: The '&*' can be found in a number of places in CodeGen now.</div><div class="">You can try to reduce the instances by streamlining your APIs to switch less between MachineBasicBlock::iterator and MachineInstr*; After all you can convert between the two at zero runtime costs with either &* or MI->getIterator(). However I would expect that some *& instances remain no matter what and that this is not really a problem.</div><div class=""><br class=""></div><div class="">- Matthias</div><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 30, 2017, at 3:39 AM, Daniel Berlin via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">IIRC, a lot of these are where implicit operators were removed (in part because they triggered in places they shouldn't and caused bugs).<div class="">Some of the others are simply because we now have api inconsistencies where some things are ilists (which have iterators that give references) and some iplists (which have iterators that give pointers)</div><div class="">It'd be nice to use pointer_iterator to clean those up so the API was consistent.</div><div class=""><br class=""></div><div class="">There's at least one case i know of where the inconsistency is caused by a bit of design we'd have to clean up:<br class=""><br class=""></div><div class="">It's not possible to have two iplists for the same type, one owning, one not, because ilist_traits is per-type, not per-tag.</div><div class=""><br class=""></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Mon, Jan 30, 2017 at 3:17 AM, David Chisnall via llvm-dev <span dir="ltr" class=""><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 30 Jan 2017, at 11:11, Martin J. O'Riordan via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:<br class="">
><br class="">
> At the moment I am in the process of getting our out-of-tree compiler up to date with respect to the v4.0 branch, and thankfully all is going well. However, one of the most common changes I have had to make has to do with iterations over machine instructions and basic blocks.<br class="">
><br class="">
> These are changes I have had to make incrementally each time we catch up with a release of LLVM, and basically the issue is that I have to replace something like:<br class="">
><br class="">
> void foo(MachineInstruction* x);<br class="">
> MachineBasicBlock::iterator index = ...;<br class="">
><br class="">
> foo(index);<br class="">
> to:<br class="">
> foo(&*index);<br class="">
><br class="">
> This pattern of having to make this edit (adding the ‘&*’) looks really scary to me, I am always nervous of expressions that look like this, and over the past three or so releases we have had to make similar changes (usually, but not always to various MI/MBB iterators).<br class="">
><br class="">
> So my guess is that we are using the wrong iterator, or an inappropriate iterator; but there are so many iterators now that I wonder if there is guidance on which iterator is most appropriate to a particular context or usage.<br class="">
><br class="">
> The main types of iteration we need are over the instructions in a basic-block, sometimes including the MI contents of bundles, and sometimes over the bundle (treating them as a single MI). And of course the ‘const’ versus editable iterations.<br class="">
><br class="">
> Does anybody have pointers to existing developer documentation advising which iterators to use, when and how? Or have advice they can give here in this forum if such documentation does not exist (I haven’t found it if it does exist)?<br class="">
><br class="">
> I think it would be really useful information in general, and since our code is originally derived from LLVM v2.7, as LLVM modernises, we often have to make tweaks to code built a long time ago to get it working again. The trick of adding ‘&*’ works, but is deeply inelegant and error-prone, and I’m pretty sure that it can be made a lot cleaner if we use the right iterator for the job.<br class="">
<br class="">
</span>I don’t have an answer, but I’ve just been through exactly the same process. A huge number of the build failures after my last merge from upstream were fixed by adding &* in front of an iterator. Like you, this made me slightly nervous (&*x and x having different types in general makes me slightly unhappy, but needing to explicitly take advantage of this fact is a lot worse). Is there a better fix, or should we be adding user-defined conversion operators for implicitly casting the iterator to the pointer type?<br class="">
<br class="">
David<br class="">
<br class="">
______________________________<wbr class="">_________________<br class="">
LLVM Developers mailing list<br class="">
<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class="">
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/<wbr class="">mailman/listinfo/llvm-dev</a><br class="">
</blockquote></div><br class=""></div>
_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<br class=""></div></blockquote></div><br class=""></body></html>