search for: codgen

Hi, On Sat, Oct 22, 2011 at 12:03 PM, David Peixotto <dmp at rice.edu> wrote: > I'm having a problem with the code generated for the popcnt intrinsic on MacOSX. The `llc` program will generate the assembly just fine, but the assembler fails with the error: > >   suffix or operands invalid for `popcnt' > > The problem is that the mac assembler does not support length

I'm having a problem with the code generated for the popcnt intrinsic on MacOSX. The `llc` program will generate the assembly just fine, but the assembler fails with the error: suffix or operands invalid for `popcnt' The problem is that the mac assembler does not support length suffixes on the popcnt instruction (e.g. {w,l,q} suffixes). GCC handles this by not adding the suffixes to

...e intent of these attributes are to control the codegen pipeline only. Of course this is all based on the assumption that using the optimization level used during bitcode generation should also be used with LTO in the codegen pipeline. I don't have a strong opinion either way. I just want codgen to respect the fact that I specified -O3 during both the bitcode generation and link steps, but that's not the case anymore. :) Chad > > Thanks, > > -- > Mehdi > >> Assuming the argument is reasonable (it make sense to me), I was >> hoping >> to sol...

...t; > Message-ID: <A8FD895A-6307-402D-A38D-A3BF39FF43C6 at apple.com> > Content-Type: text/plain; CHARSET=US-ASCII > > Exactly as Jim said :) > > I'm only talking about releases and release blockers. Its also a bit of a > grey area when you are talking about just ARM codgen tests in the > regression test suite because those should always be passing regardless > of what target/os you are testing on (assuming you built the arm backend > which the release team typically does). As it stands now we don't have > ARM as a supported target just because there i...

On Wed, Mar 25, 2015 at 10:28 AM, Tim Northover <t.p.northover at gmail.com> wrote: > >> Why? i16mem here stands for the pointer, not the actual memory. A > >> store doesn't define a pointer, so why would it be in "outs"? > > > > Then why does this "i16mem:$dst" belongs to "ins"? Is that wrong, > correct? > > Think

...ributes are to control the codegen pipeline > only. Of course this is all based on the assumption that using the > optimization level used during bitcode generation should also be used with > LTO in the codegen pipeline. > > I don't have a strong opinion either way. I just want codgen to respect > the fact that I specified -O3 during both the bitcode generation and link > steps, but that's not the case anymore. :) > > Chad > > > >> Thanks, >> >> -- >> Mehdi >> >> Assuming the argument is reasonable (it make sense to...

...t; > Message-ID: <A8FD895A-6307-402D-A38D-A3BF39FF43C6 at apple.com> > Content-Type: text/plain; CHARSET=US-ASCII > > Exactly as Jim said :) > > I'm only talking about releases and release blockers. Its also a bit of a > grey area when you are talking about just ARM codgen tests in the > regression test suite because those should always be passing regardless > of what target/os you are testing on (assuming you built the arm backend > which the release team typically does). As it stands now we don't have > ARM as a supported target just because there i...

...ol the codegen pipeline >> only. Of course this is all based on the assumption that using the >> optimization level used during bitcode generation should also be used with >> LTO in the codegen pipeline. >> >> I don't have a strong opinion either way. I just want codgen to respect >> the fact that I specified -O3 during both the bitcode generation and link >> steps, but that's not the case anymore. :) >> >> Chad >> >> >> >>> Thanks, >>> >>> -- >>> Mehdi >>> >>> As...

...call instruction is seen that > references a function not in the proper tree. That is, the > disjointness of the trees will be enforceable even in user assembly > with a bit of cooperation from the assembler. We used this in the AsmPrinter to rename intrinsics called from ISR code. As, codgen currently ties the libcall names in ISelLowering constructors and then doesn't allow changing the name dynamically. So we'll still need to handle the same in AsmPrinter. Thanks - Sanjiv

...opBottomUp patch file shows almost the same execution performance with clang. That is because no invalid scops is detected with this patch file at all. I am still confused. So you are saying Polly reduces the run-time from 19 to 14 secs for huffbench? This is nice, but very surprising for the no-codgen runs, no? >>:-( I think here an up-to-date non-polly to polly comparision would come >>handy to see which benchmarks we still see larger performance >>regressions. And if the bottom-up scop detection actually helps here. >>As this is a larger patch, we should really have a...

Le mar. 3 avr. 2018 à 12:47, via llvm-dev <llvm-dev at lists.llvm.org> a écrit : > All, > A recent commit, D43040/r324557, changed the behavior of the gold plugin > when compiling with LTO. The change now causes the codegen optimization > level to default to CodeGenOpt::Default (i.e., -O2) rather than use the > LTO optimization level. The argument was made that the LTO

...> > Message-ID: <A8FD895A-6307-402D-A38D-A3BF39FF43C6 at apple.com> > Content-Type: text/plain; CHARSET=US-ASCII > > Exactly as Jim said :) > > I'm only talking about releases and release blockers. Its also a bit of a > grey area when you are talking about just ARM codgen tests in the > regression test suite because those should always be passing regardless > of what target/os you are testing on (assuming you built the arm backend > which the release team typically does). As it stands now we don't have > ARM as a supported target just because there i...

No. Note the qualifying phrase "for releases" on Tanya's statement. If, during release testing, a regression is found on ARM compared to 2.9 results, it is not required by process to be considered a release blocker. That does not mean features can or should be enabled which knowingly break ARM. That's an entirely different situation. -Jim On Oct 8, 2011, at 9:59 AM, Rotem,

At 2013-07-31 22:50:57,"Tobias Grosser" <tobias at grosser.es> wrote: >On 07/30/2013 10:03 AM, Star Tan wrote: >> Hi Tobias and all Polly developers, >> >> I have re-evaluated the Polly compile-time performance using newest >> LLVM/Polly source code. You can view the results on >> http://188.40.87.11:8000 >>

Hi Tanya, The new type-legalization mode (-promote-elements) which enables vector-select in LLVM (and a nice perf boost for several workloads), is currently disabled because of a _single_ bug in the ARM codegen which makes a few tests fail. If ARM is not a supported target, can I mark these tests as 'XFAIL' and enable vector-select support in LLVM ? Thanks, Nadav -----Original

...een that > > references a function not in the proper tree. That is, the > > disjointness of the trees will be enforceable even in user assembly > > with a bit of cooperation from the assembler. > We used this in the AsmPrinter to rename intrinsics called from ISR > code. As, codgen currently ties the libcall names in ISelLowering > constructors and then doesn't allow changing the name dynamically. So > we'll still need to handle the same in AsmPrinter. > > Thanks > - Sanjiv >

...file shows almost the same execution performance with clang. That is because no invalid scops is detected with this patch file at all. > >I am still confused. So you are saying Polly reduces the run-time from >19 to 14 secs for huffbench? This is nice, but very surprising for the >no-codgen runs, no? Yes, Polly reduces the run-time from 19 to 14 secs for the no-codegen run. > >>>:-( I think here an up-to-date non-polly to polly comparision would come >>>handy to see which benchmarks we still see larger performance >>>regressions. And if the bottom-up scop...

Hi Ali, Thanks for bringing this up. You're definitely under very tight design constraints from the hardware. I can certainly sympathize. I think two design elements are being conflated here, and it would be worthwhile splitting them out. For correctness, you need to make sure any routines called from an ISR don't clobber equivalent routines called from mainline code. For

All, A recent commit, D43040/r324557, changed the behavior of the gold plugin when compiling with LTO. The change now causes the codegen optimization level to default to CodeGenOpt::Default (i.e., -O2) rather than use the LTO optimization level. The argument was made that the LTO optimization level should control the amount of cross-module optimizations done by LTO, but it should not

...A8FD895A-6307-402D-A38D-A3BF39FF43C6 at apple.com> >> Content-Type: text/plain; CHARSET=US-ASCII >> >> Exactly as Jim said :) >> >> I'm only talking about releases and release blockers. Its also a bit of a >> grey area when you are talking about just ARM codgen tests in the >> regression test suite because those should always be passing regardless >> of what target/os you are testing on (assuming you built the arm backend >> which the release team typically does). As it stands now we don't have >> ARM as a supported target just...