similar to: InstIterator

Within a basic block this is just normal iterator usage/manipulation: for (instr : llvm::make_range(FromInstruction.getIterator(), ToInstruction.getIterator())) { ... } Use std::next() on ToInstruction.getIterator() if you want it included. - Matthias > On Apr 9, 2018, at 10:04 AM, Alexandre Isoard via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hello, > > Is there

Hello David, I am having an issue with some custom intrinsics that return a token value: InstCombine deletes the users of the token but not the instruction that creates the token itself. The IR is still valid but it's wasted. The source of the issue is coming from an old patch of yours: commit 7204cff0a121ebc770cf81f7f94679ae7324daae Author: David Majnemer <david.majnemer at

Yes, it's still respected in this case, as the only instructions that will be deleted have been RAUW with undef. Originally, all instructions where RAUW but only non-EHPad were deleted (that means EHPad were RAUW but not deleted). Then it was later patched by not RAUW token instructions and now not deleting EHPad nor token instructions. My assumption is that the instructions we wanted to

I did not observe any assertion. In addition, the documentation ( https://llvm.org/docs/LangRef.html#undefined-values) says: The string ‘undef’ can be used anywhere a constant is expected, and indicates that the user of the value may receive an unspecified bit-pattern. Undefined values may be of any type (other than ‘label’ or ‘ void’) and be used anywhere a constant is permitted. Either way,

Hello, We have some transformations based on SCEV and they usually end-up making heuristic decision based on SCEV comparison. While there are some situations where the comparison is trivial (subtract then look at the sign of the range), there are also a lot of situation where it is not (the range contains 0 strictly [aka. not on the boundary]). And we then take a "default" choice. To

Hi, As far as I understand, AssumptionTracker is just a compile-time optimization to avoid having to iterate over instructions to find a relevant @llvm.assume. In case of @llvm.expect, one can just look up the definition, which would be the @llvm.expect. Some time ago there was a patch that replaced AssumptionTracker but got reverted. I see an issue with @llvm.expect's design. It should not

Hi, Recently, I am working on some information collection on the machine instruction (MachineInstr) level. But, sometimes, I need check the corresponding IR level instruction of the a machine instruction. When visiting a machine instruction which is a call (MachineInstr::isCall()), I need to check the arguments of this call site. I know that the CallSite class provides good facility for this

Hi Kuba, Thanks for your advice in your previous letter. During last week, I have read the documents on Doxygen and the source code of the DomTreeBase/DomTree/PostDomTree/DeferredDominance class, I believe now I have a much better understanding on the relationship between these classes and how DeferredDominance class performs lazy updates. I have also learnt the current usage and drawbacks of

"Duncan P. N. Exon Smith via llvm-dev" <llvm-dev at lists.llvm.org> writes: >> On 2015-Oct-20, at 11:23, Reid Kleckner <rnk at google.com> wrote: >> >> I think the implicit iterator conversions are much less important >> now that we have range based for loops, but I still like having >> them. > > IMO, if a developer has an ilist iterator

Hi Kuba, Thanks for your clarification on the project in the previous letter. I have submitted a proposal draft at the GSoC website, the draft has been shared with the LLVM organization. I will appreciate it if you can give me some advice on the proposal. This draft can be viewed by the organization. (If you do not have access, please mail me, and I will give you the link.) I am looking forward

Hi Chijun, Great, seems like you did a lot of progress and understand the issues quite well! I have done some early sketch on the API of the new updater class. > From my current understanding, to solve the fragmentation problem of > the API, the new class first, need to maintain the DomTree and > PostDomTree class and deprecate the DefferredDominance class. > There are a couple of

Hi! Attached patches split init.trampoline into adjust.trampoline and init.trampoline, like in gcc. As mentioned in the previous mail, I've not made a documentation patch, since I'm not sure about what the documented semantics of llvm.adjust.trampoline should be. Thanks! -- Sanjoy Das http://playingwithpointers.com -------------- next part -------------- A non-text attachment was

Hi Chijun, I left you my feedback in the doc (+ some nitpicks). Overall, it looks very solid and shows you understand the problem well and know what to expect. Your proposed timeline is reasonable and I don't see any major things to improve there. Don't hesitate to reach out if you have any questions related to my comments (either here or in the document). Thanks, Kuba On Wed, Mar 21,

Hi Kuba, Thanks for your feedback. I have made some improvements on the proposal according to your feedback and clarify something on the time availability. I left comments on the questions you asked in the doc. Please check it out. Thanks, Chijun 2018-03-22 10:37 GMT+08:00 Jakub (Kuba) Kuderski <kubakuderski at gmail.com>: > Hi Chijun, > > I left you my feedback in the doc (+

Hi Chijun, Thanks for your interest in the project. I have gone through most of the LLVM Kaleidoscope tutorial and I have > watched the video of the presentation “Dominator Trees and incremental > updates that transcend time” presented on the 2017 LLVM Developers’ > Meeting. I have also started to understand the algorithm mentioned in > the comments of the code related to the

Hello, I’m an undergraduate student studying CS in the South China University of Technology. I have been using clang compiler and related tools since I started studying C++ and I would like to work on LLVM in this year’s GSoC. I am interested in “Implement a single updater class for Dominators”. [1] I have achieved a bronze medal in the 2017 ACM-ICPC Asia Xian Regional Contest [2] (being a

Chris Lattner wrote: > > inline IIty operator*() const { return BI; } > > inline IIty operator->() const { return operator*(); } > > > > So operator* works as if value_type is Instruction*, but operator-> works > > as if value_type is Instruction. Hmm ;-) > > Yeah, fishy huh? :) Yea, a bit. I've decided that before changing that I'd better

And again... LLVM_BUILD_LLVM_DYLIB:BOOL=ON LLVM_LINK_LLVM_DYLIB:BOOL=ON This one is the good one... maybe. On Tue, Sep 6, 2016 at 11:35 PM, Alexandre Isoard < alexandre.isoard at gmail.com> wrote: > That is because I mistyped it: > LLVM_ENABLE_LLVM_DYLIB:BOOL=ON > LLVM_LINK_LLVM_DYLIB:BOOL=ON > > On Tue, Sep 6, 2016 at 11:31 PM, Wink Saville <wink at saville.com>

On 2014 Mar 2, at 22:27, Chandler Carruth <chandlerc at google.com> wrote: > > On Sun, Mar 2, 2014 at 10:13 PM, Saleem Abdulrasool <compnerd at compnerd.org> wrote: > On Sun, Mar 2, 2014 at 9:26 PM, Chris Lattner <sabre at nondot.org> wrote: > > On Mar 2, 2014, at 8:53 PM, Renato Golin <renato.golin at linaro.org> wrote: > > > On 3 March 2014

On Fri, 23 Apr 2004, Vladimir Prus wrote: > Yea, I've noticed that. However, it looks like inst_iterator is iterator over > pointers. Oh, wait a minite, that's the current code: > > inline IIty operator*() const { return BI; } > inline IIty operator->() const { return operator*(); } > > So operator* works as if value_type is Instruction*, but operator->