similar to: How to print all pass when using -flto floag ?

for example I want to insert a new machine bb “before” a specific machine bb. or split a mbb and keep the later one as the original one. (to keep the label/Blackadder's correct t) (or keep other property of mbb) so I need to transfer the original mbb's predecessor to the new mbb. Nicolai Hähnle <nhaehnle at gmail.com> 於 2020年3月13日 週五 23:57 寫道： > On Fri, Mar 13, 2020 at

So if I want to know whether a CallInst is a C++ virtual call or not. I have to get the information at frontend/Clang. and then pass the information to middle-end/LLVM IR by myself. Is it right? Thank you David Blaikie <dblaikie at gmail.com> 於 2020年6月19日 週五 上午1:26寫道： > On Thu, Jun 18, 2020 at 9:53 AM PenYiWang via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > >

Hi Hal, In that case what is the best way to query whether there is a loop carried dependence between B[j] and A[j] at i-loop level? We were operating under the assumption of 'conservatively correct' behavior of alias analysis in the function scope? Thanks, Pankaj From: Finkel, Hal J. <hfinkel at anl.gov> Sent: Tuesday, March 17, 2020 11:50 AM To: Hiroshi Yamauchi <yamauchi at

Hi I want to replace all the return instructions in the program with pop <reg>; jmp <reg>. Should I use IRBuilder in LLVM IR level? I found that there is a IRBuilder::CreateIndirectBr Or Should I modify the code in lib/Target/X86/X86ISelLowering.cpp in backend ? I found that there is a X86TargetLowering::LowerCall Which is better? Thanks -------------- next part --------------

My understanding is that alias analysis returns results in the function scope, not in loop scope. Since both the phis access both global arrays, that should results in BasicAA conservatively returning MayAlias. I debugged this a little bit and narrowed it down to the section of the code in BasicAAResult::aliasPHI() which has this comment- // Analyse the PHIs' inputs under the assumption

Hi cschen, Here are the test scripts which I written when I was developing ARM exception handling support: https://github.com/loganchien/libcxx-scripts The script should work on Debian wheezy (cross-compiling from amd64 to armhf.) In general, here are the necessary steps: 1. Get a working arm-linux-gnueabihf gcc/g++ toolchain (for the headers and libraries) 2. Setup the include search path

@Zola, Eric, I really feel the communication and reasoning here is problematic. From my perspective, you removed stuff "we don't need", ignoring whether it is used, and then let people figure out how to deal with the result. What I most dislike about the process most is how questions and concerns are then ignored or played down. Thanks,   Johannes On 5/12/20 2:10 PM,

Just push :) On Tue, May 12, 2020, 8:46 AM Hiroshi Yamauchi <yamauchi at google.com> wrote: > I was also using "git llvm push" to commit, sort of out of habit. What's a > recommended, alternative way to push? > > On Mon, May 11, 2020 at 11:57 AM Johannes Doerfert via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> I was actually using `git

On Fri, May 11, 2018 at 2:37 PM, Hiroshi Yamauchi <yamauchi at google.com> wrote: > > > On Thu, May 10, 2018 at 12:49 PM Daniel Berlin <dberlin at dberlin.org> > wrote: > >> >> >> On Thu, May 10, 2018 at 12:05 PM, Hiroshi Yamauchi <yamauchi at google.com> >> wrote: >> >>> >>> >>> On Wed, May 9, 2018 at 8:24

For some reason this thread seems to be gone in a wrong direction. I'm sorry for that. The discussion on the RFC asked for a reason to keep the script, I think we heard reasons to do so (due to branches). Now, I was unable to determine if the `git llvm` scripts was removed "just as part of the bunch" or if we expect a problem with the script. If it is the former, are there

On Fri, May 11, 2018 at 7:20 PM Hal Finkel <hfinkel at anl.gov> wrote: > > On 05/11/2018 08:40 PM, Daniel Berlin via llvm-dev wrote: > > > > On Fri, May 11, 2018 at 2:37 PM, Hiroshi Yamauchi <yamauchi at google.com> > wrote: > >> >> >> On Thu, May 10, 2018 at 12:49 PM Daniel Berlin <dberlin at dberlin.org> >> wrote: >>

Hi I want to ask a question. (Maybe it is a trivial question.) I found that there is transferSuccessors() in MachineBasicBlcok So that when manipulating MachineBasicBlock, we can use transferSuccessors to update the CFG easily. Why there is not transferPredecessors in MachineBasicBlcok ? Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL:

TBH, all I initially asked for, still ask for, is a reason why `git llvm` was being removed. Your email was the only one that hinted on a reason. (more below) On 5/12/20 4:00 PM, David Blaikie wrote: > On Tue, May 12, 2020 at 1:50 PM Johannes Doerfert via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> @Zola, Eric, >> >> >> I really feel the

On Thu, May 10, 2018 at 12:05 PM, Hiroshi Yamauchi <yamauchi at google.com> wrote: > > > On Wed, May 9, 2018 at 8:24 PM Daniel Berlin <dberlin at dberlin.org> wrote: > >> >> >> On Wed, May 9, 2018 at 10:39 AM, Hiroshi Yamauchi <yamauchi at google.com> >> wrote: >> >>> >>> >>> On Tue, May 8, 2018 at 11:15 AM

I mentioned this earlier in the thread - I would like to see something like D41574 in the optimizer. It's optimizing code that no other pass does currently, and I don't see any other near-term proposal that gets us those optimizations. Omer, can you rebase that to trunk? I think a header has moved, so it doesn't build as-is. I'd like to know if it can catch the cases in D45842. If

On 05/11/2018 08:40 PM, Daniel Berlin via llvm-dev wrote: > > > On Fri, May 11, 2018 at 2:37 PM, Hiroshi Yamauchi <yamauchi at google.com > <mailto:yamauchi at google.com>> wrote: > > > > On Thu, May 10, 2018 at 12:49 PM Daniel Berlin > <dberlin at dberlin.org <mailto:dberlin at dberlin.org>> wrote: > > > > On Thu, May

Hi Zola, thanks for the response. People brought forth reasons why we should not have git scripts in the repo. I'm not sure about that but as long as we don't see other people coming forward, we don't need it in the repo. I can have a private copy after all. Thanks again,   Johannes On 5/15/20 2:16 PM, Zola Bridges via llvm-dev wrote: > Hey everyone, > > I missed

I don't exactly remember when I last tried it and I didn't realize there was r342896. I'll check it out. Thanks. On Wed, Jul 10, 2019 at 1:14 PM Philip Pfaffe <philip.pfaffe at gmail.com> wrote: > > Printing was implemented in r342896. > @Hiroshi: Are there specific issues or limitations you encountered with it? > > Cheers, > Philip > > On Wed, Jul 10,

Hello, I have just read the LLVM paper (CGO'04) and thought it was an interesting project. And, I am wondering if there exists a Java frontend (that compiles Java bytecode to LLVM code) as the paper mentioned. If there is any, what is the status of it? Pardon me if this information is obviously provided somewhere in the LLVM web site. Best regards, Hiroshi Yamauchi Purdue University

I had a chance to try -print-after-all with NPM. It seems like there's still no output for the passes before objc-arc-contract (which is basically what I saw before.) Does anyone else see this? Are we talking about the same thing? *** IR Dump After ObjC ARC contraction *** *** IR Dump After Pre-ISel Intrinsic Lowering *** *** IR Dump After Expand Atomic instructions *** *** IR Dump After