search for: useaa

The flag -enable-aa-sched-mi should do what you want you want in the MachineScheduler pass. If you want to do it in the selection DAG, there is a subtarget hook that might do it: TargetSubtargetInfo::useAA() LLVM won’t generate the schedule you want anyway for Intel core processors, but the alias analysis can be useful in general. -Andy On Dec 16, 2013, at 6:03 AM, Haishan <hndxvon at 163.com> wrote: > At 2013-12-15 22:43:34,"Caldarale, Charles R" <Chuck.Caldarale at unisys....

...fter=codegenprepare < %s >%t 2>&1 && FileCheck --check-prefix=CHECK-NoAA <%t %s WARNING: Skipping non-FileChecked RUN line: llc -O3 -aarch64-enable-gep-opt=true -mattr=+use-aa -print-after=codegenprepare < %s >%t 2>&1 && FileCheck --check-prefix=CHECK-UseAA <%t %s WARNING: Skipping non-FileChecked RUN line: llc -O3 -aarch64-enable-gep-opt=true -print-after=codegenprepare -mcpu=cyclone < %s >%t 2>&1 && FileCheck --check-prefix=CHECK-NoAA <%t %s WARNING: Skipping non-FileChecked RUN line: llc -O3 -aarch64-enable-gep-opt=tru...

At 2013-12-15 22:43:34,"Caldarale, Charles R" <Chuck.Caldarale at unisys.com> wrote: >> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] >> On Behalf Of Haishan >> Subject: [LLVMdev] Question about Pre-RA-schedule in LLVM3.3 > >> My clang version is 3.3 and debug build. > >> //test.c >> int a[6] = {1, 2, 3, 4, 5,

...re > < %s >%t 2>&1 && FileCheck --check-prefix=CHECK-NoAA <%t %s > WARNING: Skipping non-FileChecked RUN line: llc -O3 > -aarch64-enable-gep-opt=true -mattr=+use-aa -print-after=codegenprepare > < %s >%t 2>&1 && FileCheck --check-prefix=CHECK-UseAA <%t %s > WARNING: Skipping non-FileChecked RUN line: llc -O3 > -aarch64-enable-gep-opt=true -print-after=codegenprepare -mcpu=cyclone < > %s >%t 2>&1 && FileCheck --check-prefix=CHECK-NoAA <%t %s > WARNING: Skipping non-FileChecked RUN line: llc -O3 > -aarc...

...%s >%t 2>&1 && FileCheck --check-prefix=CHECK-NoAA <%t %s > WARNING: Skipping non-FileChecked RUN line: llc -O3 > -aarch64-enable-gep-opt=true -mattr=+use-aa -print-after=codegenprepare > < %s >%t 2>&1 && FileCheck --check-prefix=CHECK-UseAA <%t %s > WARNING: Skipping non-FileChecked RUN line: llc -O3 > -aarch64-enable-gep-opt=true -print-after=codegenprepare -mcpu=cyclone < > %s >%t 2>&1 && FileCheck --check-prefix=CHECK-NoAA <%t %s > WARNING: Skipping non-FileChecked RUN line: ll...

...;1 && FileCheck --check-prefix=CHECK-NoAA <%t %s > > WARNING: Skipping non-FileChecked RUN line: llc -O3 > > -aarch64-enable-gep-opt=true -mattr=+use-aa > -print-after=codegenprepare > > < %s >%t 2>&1 && FileCheck --check-prefix=CHECK-UseAA <%t %s > > WARNING: Skipping non-FileChecked RUN line: llc -O3 > > -aarch64-enable-gep-opt=true -print-after=codegenprepare > -mcpu=cyclone < > > %s >%t 2>&1 && FileCheck --check-prefix=CHECK-NoAA <%t %s > > WARNING: Skipping non...

...heck --check-prefix=CHECK-NoAA <%t %s > >     WARNING: Skipping non-FileChecked RUN line: llc -O3 > >     -aarch64-enable-gep-opt=true -mattr=+use-aa > -print-after=codegenprepare > >     < %s >%t 2>&1 && FileCheck --check-prefix=CHECK-UseAA <%t %s > >     WARNING: Skipping non-FileChecked RUN line: llc -O3 > >     -aarch64-enable-gep-opt=true -print-after=codegenprepare > -mcpu=cyclone < > >     %s >%t 2>&1 && FileCheck --check-prefix=CHECK-NoAA <%t %s > > ...

For the tests that are changing, you should see if those changes are improvements, regressions, or neutral. This is unfortunately not always obvious for x86 asm, so feel free to just post those diffs in an updated version of the patch at D37896. If the test files have auto-generated assertions (look for this string on the first line of the test file: "NOTE: Assertions have been autogenerated

Hi all, I'm looking into the performance difference of a benchmark compiled with NVCC vs NVPTX (coming from Julia, not CUDA C) and I'm seeing a significant difference due to PTX instruction ordering. The relevant source code consists of two nested loops that get fully unrolled, doing some basic arithmetic with values loaded from shared memory: > #define BLOCK_SIZE 16 > >

...If you look at AMDGPU/AMDGPUTargetMachine.cpp, you'll see > calls like this: > > DAG->addMutation(createLoadClusterDAGMutation(DAG->TII, DAG->TRI)); > > and I think that you probably want to do the same. > > Also, you might want to override the subtarget's useAA() method to > return true (as this gives more freedom to the scheduler to move memory > accesses around to do this kind of clustering). > > -Hal > > > > > Thanks, > > -- > Hal Finkel > Lead, Compiler Technology and Programming Languages > Leadership Comput...

...> SDAG at the basic block level. > > Isn't addr-sink-using-gep already a thing? Yes, I'm not sure why I wrote that (maybe I saw the new addrSinkUsingGEPs in a patch and misremembered). It looks like what I actually did was attempt to decouple the logic. It's currently based on useAA, which seems to be an orthogonal question to me, so I added a new virtual function hook. I'm now suspicious of the logic there too, though. I'll inspect it further before uploading anything for review. > > Second is the intrusiveness. On the plus side it's less intrusive than &gt...

As you may have noticed, we released a 64b S4 chip that runs an ILP32 variant of the AArch64 ABI, and now we'd like to upstream that work. I've pushed preliminary patches to https://github.com/TNorthover/llvm-project/pull/1/commits (arm64_32 branch in that repo) to accompany this RFC. The changes divide fairly neatly into three categories. First, there's AArch64 ILP32 support, which

On Nov 20, 2013, at 10:38 PM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- >> From: "Evan Cheng" <evan.cheng at apple.com> >> To: "Hal Finkel" <hfinkel at anl.gov> >> Cc: "LLVM" <llvmdev at cs.uiuc.edu>, "Junbum Lim" <junbums at gmail.com> >> Sent: Wednesday, November 20, 2013

----- Original Message ----- > From: "Evan Cheng" <evan.cheng at apple.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVM" <llvmdev at cs.uiuc.edu>, "Junbum Lim" <junbums at gmail.com> > Sent: Wednesday, November 20, 2013 7:48:13 PM > Subject: Re: [LLVMdev] sinking address computing in CodeGenPrepare > >