similar to: [LLVMdev] TSVC/Equivalencing-dbl

Hi Hal, On 05/10/12 20:32, Hal Finkel wrote: > ----- Original Message ----- >> From: "Duncan Sands" <duncan.sands at gmail.com> >> To: "Hal Finkel" <hfinkel at anl.gov> >> Cc: llvmdev at cs.uiuc.edu >> Sent: Friday, October 5, 2012 12:10:03 PM >> Subject: Re: TSVC/Equivalencing-dbl >> >> Oops, I ran the testsuite wrong:

----- Original Message ----- > From: "Duncan Sands" <duncan.sands at gmail.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: llvmdev at cs.uiuc.edu > Sent: Friday, October 5, 2012 12:10:03 PM > Subject: Re: TSVC/Equivalencing-dbl > > Oops, I ran the testsuite wrong: read clang output for dragonegg > output. Okay, can you resummarize? Do

Hi Hal, To get my understanding right, is this a test-case problem or there is a problem with x86 code generation?. I can spend some time to look into the problem. Thanks, Shivaram -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Hal Finkel Sent: Saturday, October 06, 2012 1:57 AM To: Duncan Sands Cc: llvmdev at cs.uiuc.edu

----- Original Message ----- > From: "Duncan Sands" <duncan.sands at gmail.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: llvmdev at cs.uiuc.edu > Sent: Friday, October 5, 2012 2:50:06 PM > Subject: Re: TSVC/Equivalencing-dbl > > Hi Hal, > > On 05/10/12 20:32, Hal Finkel wrote: > > ----- Original Message ----- > >>

On Sat, 2011-10-29 at 15:16 -0500, Hal Finkel wrote: > On Sat, 2011-10-29 at 14:02 -0500, Hal Finkel wrote: > > On Sat, 2011-10-29 at 12:30 -0500, Hal Finkel wrote: > > > Ralf, et al., > > > > > > Attached is the latest version of my autovectorization patch. llvmdev > > > has been CC'd (as had been suggested to me); this e-mail contains > >

Oops, I ran the testsuite wrong: read clang output for dragonegg output.

PS: Here's how I can reproduce with clang on linux: clang -S -o tsc.ll -O0 -flto -std=gnu99 tsc.c ; clang -S -o dummy.ll -O0 -flto -std=gnu99 dummy.c ; opt -std-compile-opts tsc.ll -S -o tsc.1.ll ; opt -std-compile-opts dummy.ll -S -o dummy.1.ll ; llvm-link tsc.1.ll dummy.1.ll -S -o total.ll ; opt -std-link-opts total.ll -S -o total.1.ll ; llc total.1.ll ; gcc -o z total.1.s The program

On Sat, 2011-10-29 at 14:02 -0500, Hal Finkel wrote: > On Sat, 2011-10-29 at 12:30 -0500, Hal Finkel wrote: > > Ralf, et al., > > > > Attached is the latest version of my autovectorization patch. llvmdev > > has been CC'd (as had been suggested to me); this e-mail contains > > additional benchmark results. > > > > First, these are preliminary

On Sat, 2011-10-29 at 12:30 -0500, Hal Finkel wrote: > Ralf, et al., > > Attached is the latest version of my autovectorization patch. llvmdev > has been CC'd (as had been suggested to me); this e-mail contains > additional benchmark results. > > First, these are preliminary results because I did not do the things > necessary to make them real (explicitly quiet the

Ralf, et al., Attached is the latest version of my autovectorization patch. llvmdev has been CC'd (as had been suggested to me); this e-mail contains additional benchmark results. First, these are preliminary results because I did not do the things necessary to make them real (explicitly quiet the machine, bind the processes to one cpu, etc.). But they should be good enough for discussion.

Does anyone have a leads or ideas how one could us the Observers to detect and act on single vs double clicks on objects/links? _______________________________________________ Rails-spinoffs mailing list Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs

Dear R users, I have been searching thru the documentation of R but did not find anything about reading or manipulating a binary data block file (.DBL).a link to one example https://echange-fichiers.inra.fr/get?k=5Hzw2B1wZDng9ztO34E -- View this message in context: http://r.789695.n4.nabble.com/can-R-read-a-binary-data-block-file-DBL-tp4652654.html Sent from the R help mailing list archive

Summary ======= I'm planning on adjusting SimplifyCFG so that it doesn't turn two-entry phi nodes into selects until later in the pass pipeline, to give passes which can understand phis but not selects more opportunity to optimize. The thing I'm trying to do which made me think of doing this is described below, but from the benchmarking I've done it looks like this is overall a

Hi, Shrink-wrapping capabilities, i.e., better placement of prologue and epilogue sequences, landed in r236507 but are not yet enabled by default. Since r236507 AArch64 is shrink-wrapping ready, meaning we can turn the pass on for this target. I’ve done the same for X86 in r 238293. Now, I need your help to test and benchmark how shrink-wrapping perform on those targets. The goal is to decide

I'm concerned that we're focusing on one side of this.  Let me point out a few concerns w/changing the canonical form here: 1. LICM does not know how to hoist or sink regions.  It does know how to hoist and sink selects. 2. InstCombine has limited support for triangles/diamonds, but fairly extensive support for selects. 3. EarlyCSE and GVN do not know how to eliminate fully

Hello, I was interested in how much Type-Based Alias Analysis helps to optimize code. For that purpose, I've compared three sets of benchmarks: compiled without TBAA, compiled with a default TBAA metadata format, and compiled with new TBAA metadata format. As a set of benchmarks, I've used the LLVM test suite (http://llvm.org/docs/TestingGuide.html#test-suite-overview) which has a lot of

Hi all, I've started looking at the GlobalMerge pass, enabled by default on ARM and AArch64. I think we should reconsider that, at least for AArch64. As is, the pass just merges all globals together, in groups of 4KB (AArch64, 128B on ARM). At the time it was enabled, the general thinking was "it's almost free, it doesn't affect performance much, we might as well use it".

> On Aug 15, 2018, at 10:57 PM, Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > On 08/15/2018 02:38 PM, Philip Reames via llvm-dev wrote: >> I'm concerned that we're focusing on one side of this. Let me point out a few concerns w/changing the canonical form here: >> >> LICM does not know how to hoist or sink regions. It does know

Hi David, I am the one who's responsible for CFLAA's refactoring in the summer. I've sent out another email on llvm-dev, and you can find more about my work in my GSoC final report. I think it is fantastic that you have done such an interesting work. I'll definitely try to help getting the code reviewed and merged in the current. After a quick glance at your patch, it seems

Hi, Sean: I'm sorry I lie. I didn't mean to lie. I did try to avoid making a *BIG* change to the IPO pass-ordering for now. However, when I make a minor change to populateLTOPassManager() by separating module-pass and non-module-passes, I saw quite a few performance difference, most of them are degradations. Attacking these degradations one by one in a piecemeal manner is wasting