similar to: Print Register Liveness Information

Note that this only works for targets that say TargetRegisterInfo::trackLivenessAfterRegAlloc()== true. > On Feb 16, 2017, at 1:21 PM, Quentin Colombet via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Anitha, > > The liveness information is usually dropped after regalloc. > Therefore the short answer is no, this information is not available before producing

I'm still slightly confused. Is the error now fixed or is there still a bug in LLVM's integrated assembler? On Mon, Mar 11, 2013 at 4:49 AM, Anitha B Gollamudi < anitha.boyapati at gmail.com> wrote: > On 11 March 2013 17:00, Duncan Sands <baldrick at free.fr> wrote: > > Hi Anitha, > > > > > >> Ah, I am taking back my above words w.r.t encoding.

Hi, Is there any existing support/on going work for zeroing buffers in llvm infrastructure? (either in the form of intrinsics or IR code buffer erasure?) My basic "grep" did not show up any. Please let me know any info on this. I will be glad to hear out! -- Anitha

Can you send the binaries compiled with and without the integrated assembler. Maybe I can figure out the encoding problem. I've been unsuccessful figuring it out myself so far. On Tue, Mar 12, 2013 at 12:34 AM, Anitha B Gollamudi < anitha.boyapati at gmail.com> wrote: > On 12 March 2013 09:51, Craig Topper <craig.topper at gmail.com> wrote: > > I'm still slightly

On 12 March 2013 09:51, Craig Topper <craig.topper at gmail.com> wrote: > I'm still slightly confused. Is the error now fixed or is there still a bug > in LLVM's integrated assembler? > The error is not fixed yet (even with fix mentioned in PR15040 http://llvm.org/bugs/show_bug.cgi?id=15040#c4) With the updated trunk, clang still gives an error when FMA4 is enabled but

On 11 March 2013 10:06, Anitha B Gollamudi <anitha.boyapati at gmail.com> wrote: > On 23 January 2013 00:20, Craig Topper <craig.topper at gmail.com> wrote: >> >> Are you still having issues with FMA4? I wonder if PR15040 is related. A >> fix was just committed. Unfortunately r173176 does not fix this. I have updated the trunk and ran...Miscompare still persists.

Hi I am seeing an issue (compiled application seg faults) when llc is used at -O1. I first need to triage out which optimization/pass is responsible for the seg fault. As such I am following this strategy: disable gradually those passes at -O1 which do not exist at -O0. For this I used -pass-debug=Structure. [ diff pasted at the end for reference] The problem is I have used almost all -disable-*

Hi, I have a simple question w.r.t the order of operands used in dag pattern matching in target files. Some of them seem intuitive. But I want to get it clarified anyway. I am using a pattern from X86InstrFMA.td in the below example. Consider FMA3 pattern (simplified). let Constraints = "$src1 = $dst" in { multiclass fma3s_rm<bits<8> opc, string OpcodeStr, X86MemOperand

On 20 November 2012 15:10, Anitha B Gollamudi <anitha.boyapati at gmail.com> wrote: > Hi > > I am seeing an issue (compiled application seg faults) when llc is > used at -O1. I first need to triage out which optimization/pass is > responsible for the seg fault. As such I am following this strategy: > disable gradually those passes at -O1 which do not exist at -O0. For >

On 7 April 2013 14:54, Sam Parker <S.Parker3 at lboro.ac.uk> wrote: > Hi Anitha, > > memri is just describing that the address contains two components, an > immediate and a register, and how to handle them in the instruction printer. > The STWU expects a memri operand, and that is what is passed from the Pat. > My confusion is how operands of STWU from "Pat

On 16 November 2012 13:41, Anitha B Gollamudi <anitha.boyapati at gmail.com> wrote: > Hi, > > I have a simple question w.r.t the order of operands used in dag > pattern matching in target files. Some of them seem intuitive. But I > want to get it clarified anyway. I am using a pattern from > X86InstrFMA.td in the below example. Consider FMA3 pattern > (simplified). >

Hi Is there some sort of restriction over class length names in td files. For e.g. something like below gives an abort with tablegen. The abort goes away when I reduce the name "my_target_intrinsics_class..." to something shorter. I have not counted the exact length limit though. Is this a known issue? defm target_intrinsic:

Hi, How do "Pat" operands get matched? I am trying to follow the example given in http://llvm.org/docs/CodeGenerator.html#selectiondag-process In the latest trunk of ppcintrinfo.td following pattern is defined: def : Pat<(pre_store i32:$rS, iPTR:$ptrreg, iaddroff:$ptroff), (STWU $rS, iaddroff:$ptroff, $ptrreg)>; I understand that input operand list i.e. ins of

Hi Anitha, memri is just describing that the address contains two components, an immediate and a register, and how to handle them in the instruction printer. The STWU expects a memri operand, and that is what is passed from the Pat. Hope that helps, Sam On 07/04/2013 10:19, Anitha B Gollamudi wrote: > Hi, > > > How do "Pat" operands get matched? I am trying to follow

On Nov 21, 2012, at 10:53 PM, Anitha B Gollamudi <anitha.boyapati at gmail.com> wrote: >> >> How do I switch to "fast" allocator at -O1? >> > > <ping> > > Not much help on register allocator issue either? llc -optimize-regalloc=0 /jakob

On Jun 25, 2013, at 1:45 AM, Anitha B Gollamudi <anitha.boyapati at gmail.com> wrote: > Is there some sort of restriction over class length names in td files. Only your own sanity, as far as I know. > For e.g. something like below gives an abort with tablegen. The abort goes away when I reduce the name "my_target_intrinsics_class..." to something shorter. I have not

Hi Anitha, > Ah, I am taking back my above words w.r.t encoding. -no-integrated-as > does fix the issue! This definitely points towards FMA4 encoding in > clang's integrated assembler. This fits into the analysis as well - > dragonegg *might not* be using integrated assembler at all. you are right, dragonegg does not use the integrated assembler. Ciao, Duncan.

Hi, When and why are nameless functions generated in LLVM IR? Also, for the clarity, is it possible for a nameless function to have external linkage? (I think not, but I would like to get it confirmed anyway) -- Anitha

Are you still having issues with FMA4? I wonder if PR15040 is related. A fix was just committed. On Wed, Nov 7, 2012 at 3:22 AM, Anitha Boyapati <anitha.boyapati at gmail.com>wrote: > > > On 7 November 2012 15:29, Duncan Sands <baldrick at free.fr> wrote: > >> >> That way the output should be exactly the same as the output dragonegg >> would >>

On 23 January 2013 00:20, Craig Topper <craig.topper at gmail.com> wrote: > > Are you still having issues with FMA4? I wonder if PR15040 is related. A > fix was just committed. It seems to be so! I will look into it immediately. Apologies for the late e-mail. I ran out of time devoted for this PR and moved on. Coincidentally, only today I came back to this PR for further