similar to: [LLVMdev] Possible bug in LLC at -O1

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 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

Hi Duncan I am facing a build error about __builtin_iceil when compiled with dragonegg using -ffast-math option. My dragonegg is built with gcc-4.7.0 (I am compiling namd spec benchmark here again). Any idea? g++ -march=bdver2 -save-temps -fplugin=/home/anboyapa/install/bin/dragonegg.so -O2 -march=bdver2 -save-temps -fplugin=/home/anboyapa/install/bin/dragonegg.so -mno-fma -mfma4 -ffast-math

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.

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

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

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.

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

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 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 All, I am facing miscompare error when running povray (and few other C/C++ benchmarks) from spec cpu2006 suite enabling FMA4 (and disabling FMA3). I have used -ffp-contract=fast to turn on this option. (Compilation options and targets pasted below). >>>>>>>> clang version 3.2 (trunk 163295:163308) (llvm/trunk 163295) Target: x86_64-unknown-linux-gnu Thread model: posix

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:

On 5 November 2012 14:32, Duncan Sands <baldrick at free.fr> wrote: > Hi Anitha, > > > http://llvm.org/bugs/show_bug.**cgi?id=14185<http://llvm.org/bugs/show_bug.cgi?id=14185> >> I am stuck on analysis. Does any one have alternate suggestions on >> debugging >> llvm? (Please refer to comments for the work done so far) >> > > try to reduce a

Hi Anitha, On 06/11/12 10:19, Anitha Boyapati wrote: > Hi Duncan > I am facing a build error about __builtin_iceil it's surely just that dragonegg doesn't have any support for this builtin. Please open a bug report with a minimal test case. Ciao, Duncan. when compiled > with dragonegg using -ffast-math option. My dragonegg is built with gcc-4.7.0 > (I am compiling namd

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

Hi Anitha, On 05/11/12 10:29, Anitha Boyapati wrote: > > > On 5 November 2012 14:32, Duncan Sands <baldrick at free.fr > <mailto:baldrick at free.fr>> wrote: > > Hi Anitha, > > > http://llvm.org/bugs/show_bug.__cgi?id=14185 > <http://llvm.org/bugs/show_bug.cgi?id=14185> > I am stuck on analysis. Does any one have

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

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

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.