similar to: LLVM Alias Analysis

Dear LLVM developers, My name is Artem Vopilov, I am a student at TU Darmstadt. I am writing to you again to ask about Alias Analysis. Now I attached IR code and C code of program I analyze with Alias Analysis. Running commands "opt -analyze -aa-eval -print-all-alias-modref-info" and for printing sets of alias "opt -analyze -aa-eval -print-alias-sets" gives me the results,

> On 14 Dec 2018, at 16:58, Doerfert, Johannes Rudolf via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Artem, > > 1) Please do not CC all the llvm lists you can find. llvm-dev is the one > for questions like this one, llvm-admin, mailman, bugs-admin, ... are > not. > > 2) Please attach the _full_ LLVM-IR you used, the ".txt" file you >

Hi Evan, Evan Cheng wrote: > The patch looks great. But I do have one comment: > > +let usesCustomDAGSchedInserter = 1 in { > + let Uses = [CR0] in { > + let Uses = [R0] in > + def ATOMIC_LOAD_ADD_I32 : Pseudo< > > The "let Uses = [R0]" is not needed. The pseudo instruction will be > expanded like this later: > > + BuildMI(BB,

Look for createVirtualRegister. These are examples in PPCISelLowering.cpp. Evan On Jul 8, 2008, at 8:24 AM, Gary Benson wrote: > Hi Evan, > > Evan Cheng wrote: >> The patch looks great. But I do have one comment: >> >> +let usesCustomDAGSchedInserter = 1 in { >> + let Uses = [CR0] in { >> + let Uses = [R0] in >> + def ATOMIC_LOAD_ADD_I32 :

Would it be acceptable to change MachineInstr::getRegInfo from private to public so I can use it from PPCTargetLowering::EmitInstrWithCustomInserter? Cheers, Gary Evan Cheng wrote: > Look for createVirtualRegister. These are examples in > PPCISelLowering.cpp. > > Evan > On Jul 8, 2008, at 8:24 AM, Gary Benson wrote: > > > Hi Evan, > > > > Evan Cheng wrote:

PPCTargetLowering::EmitInstrWithCustomInserter has a reference to the current MachineFunction for other purposes. Can you use MachineFunction::getRegInfo instead? Dan On Jul 8, 2008, at 1:56 PM, Gary Benson wrote: > Would it be acceptable to change MachineInstr::getRegInfo from private > to public so I can use it from > PPCTargetLowering::EmitInstrWithCustomInserter? > >

Hi Gary, This does not patch cleanly for me (PPCISelLowering.cpp). Can you prepare a updated patch? Thanks, Evan On Jul 10, 2008, at 11:45 AM, Gary Benson wrote: > Cool, that worked. New patch attached... > > Cheers, > Gary > > Evan Cheng wrote: >> Just cast both values to const TargetRegisterClass*. >> >> Evan >> >> On Jul 10, 2008, at 7:36

Just cast both values to const TargetRegisterClass*. Evan On Jul 10, 2008, at 7:36 AM, Gary Benson wrote: > Evan Cheng wrote: >> How about? >> >> const TargetRegisterClass *RC = is64Bit ? &PPC:GPRCRegClass : >> &PPC:G8RCRegClass; >> unsigned TmpReg = RegInfo.createVirtualRegister(RC); > > I tried something like that yesterday: > > const

Evan Cheng wrote: > How about? > > const TargetRegisterClass *RC = is64Bit ? &PPC:GPRCRegClass : > &PPC:G8RCRegClass; > unsigned TmpReg = RegInfo.createVirtualRegister(RC); I tried something like that yesterday: const TargetRegisterClass *RC = is64bit ? &PPC::GPRCRegClass : &PPC::G8RCRegClass; but I kept getting this error no matter how I arranged it:

You need to insert new basic blocks and update CFG to accomplish this. There is a hackish way to do this right now. Add a pseudo instruction to represent this operation and mark it usesCustomDAGSchedInserter. This means the intrinsic is mapped to a single (pseudo) node. But it is then expanded into instructions that can span multiple basic blocks. See

Hi Gary, The patch looks great. But I do have one comment: +let usesCustomDAGSchedInserter = 1 in { + let Uses = [CR0] in { + let Uses = [R0] in + def ATOMIC_LOAD_ADD_I32 : Pseudo< The "let Uses = [R0]" is not needed. The pseudo instruction will be expanded like this later: + BuildMI(BB, TII->get(is64bit ? PPC::LDARX : PPC::LWARX), dest) +

Chris Lattner wrote: > On Jun 27, 2008, at 8:27 AM, Gary Benson wrote: > > def CMP_UNRESw : Pseudo<(outs), (ins GPRC:$rA, GPRC:$rB, i32imm: > > $label), > > "cmpw $rA, $rB\n\tbne- La${label}_exit", > > [(PPCcmp_unres GPRC:$rA, GPRC:$rB, imm: > > $label)]>; > > } > > > > ...and

Cool, that worked. New patch attached... Cheers, Gary Evan Cheng wrote: > Just cast both values to const TargetRegisterClass*. > > Evan > > On Jul 10, 2008, at 7:36 AM, Gary Benson wrote: > > Evan Cheng wrote: > > > How about? > > > > > > const TargetRegisterClass *RC = is64Bit ? &PPC:GPRCRegClass : > > > &PPC:G8RCRegClass; >

Evan Cheng wrote: > You need to insert new basic blocks and update CFG to accomplish this. > There is a hackish way to do this right now. Add a pseudo instruction > to represent this operation and mark it usesCustomDAGSchedInserter. > This means the intrinsic is mapped to a single (pseudo) node. But it > is then expanded into instructions that can span multiple basic >

Hi, We, IBM XL Fortran compiler team, is interested in representing Fortran alias information in LLVM IR. We use the XL Fortran frontend to emit LLVM IR that includes alias information to feed to the LLVM in order to create object files. For the Fortran alias representation in LLVM IR, we considered both TBAA and ScopeAlias/NoAlias metadata approaches, we think that the ScopeAlias/NoAlias

In a code segment of my pass plugin, I try to gather AliasSets for all StoreInst, LoadInst and CallInst instructions in a function. Some behaviors of the pass puzzled me. Below is the *.ll of the test program which I run the pass on, it was get with "llvm-gcc -Wl,--disable-opt" from a rather simple *.c program. ---------------------------------- ; ModuleID = 'ptralias.bc'

Hi Chris, > >> You probably want to somehow extend TargetData to encode the address > >> space descriptions, including pointer sizes and address space > >> relationships. > > Hmm, you have an excellent point there, pointer sizes could indeed easily > > have different sizes in different address spaces... That would make > > TargetData indeed a logical

Oh, I appologize that I should not have asked about __main() ---- it appears in FAQ. But the question remains that why call to __main() can alias stack location? I think the memory location pointed by data_X pointers are not visible to __main(). In comparison, calls to printf() do not have similar effect. On 5/14/06, Nai Xia <nelson.xia at gmail.com> wrote: > > In a code segment of

Hi, Coincidentally I've been working to optimize this same case last week. I was struggling a bit to determine where to put this functionality and eventually went for the pragmatic approach of creating an experimental pass. Probably not the eventual solution, but it may provide some useful input to the discussion here. Basically, I experimented with a 'pre-inlining-transform' pass

Hi Chris, I took a haste look at the "Points-to Analysis in Almost Linear Time" by Steens , your PHD thesis and SteensGaard.cpp in LLVM this afternoon. So I think: 1. Actually the basic algorithm described originally by SteensGaard does not provide MOD/REF information for functions. 2. The context insensitive part of Data Structure Analysis (LocalAnalysis) can be deemed as an