similar to: [LLVMdev] RFC: Adding pass in X86PassConfig::addPreEmitPass for LEA optimization on Atom

Was there any development on this? I noticed that clang still produces a lea for the testcase in llvm.org/pr13320. On 28 September 2012 11:36, Nowicki, Tyler <tyler.nowicki at intel.com> wrote: > Hi, > > > > Here is an update on our proposal to improve the uses of LEA on Atom > processors. > > > > 1. Disable current generation of LEAs > > > > Due to

Hi, Here is an update on our proposal to improve the uses of LEA on Atom processors. 1. Disable current generation of LEAs Due to a 3 cycle stall between the ALU and the AGU any address generation done using math instruction will cause a stall on loads and stores which are within 3 cycles of the address generation. Consequently, the heuristics for using LEAs efficiently must know how many

On Jan 21, 2014, at 3:20 PM, Andrew Trick <atrick at apple.com> wrote: > > On Jan 21, 2014, at 2:20 PM, sebastien riou <matic at nimp.co.uk> wrote: > >> Hi, >> >> I would like to execute a MachineFunctionPass after all other passes >> which modify the machine code. >> In other words, if we call llc to generate assembly file, that pass >>

On 1/7/2013 2:15 PM, Xu Liu wrote: > > This would be ideal. How can I do the instrumentation pass after the > instruction scheduling? You could derive your own class from TargetPassConfig, and add the annotation pass in YourDerivedTargetPassConfig::addPreEmitPass. This will add your annotation pass very late, just before the final code is emitted. If you're using the X86 target,

Hi, -Does anyone know where a backend-specific optimization can be added to replace an instruction with code containing control flow? I'm interested in adding an optimization for the DIV instruction (x86-atom) which replace the IDIV/DIV with code containing control flow to select between the intended IDIV/DIV and an 8-bit DIV with movzx, as described in the Intel Atom Optimization Guide. My

Oops! No need of Call Graph! In fact, what I want to do is to find which function is the kernel function and which function is called by that kernel. Since OpenCL will make all functions called by kernels inline, I can use function attribute: Noinline to distinguish them. Sorry for bothering you. Antony Yu -- View this message in context:

Liu, This is likely a better solution for you - you do not want to mess with the scheduler unless you really have to ;) Sergei --- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Krzysztof Parzyszek > Sent:

Are you sure you are initializing your pass properly? Can you show a stripped down version of your pass? On Fri, Jun 21, 2013 at 7:27 AM, Anthony Yu <swpenim at gmail.com> wrote: > Hello, > > I want to write a modulePass in addPreEmitPass() for NVPTX, but I > encounter an assertion failed when executing clang. > > Here is my error message. > ==== > Pass 'NVPTX

So that's how it is !! Thanks! Hmm, in fact, I want to get Call Graph information in machine code stage, is there any way to get this? I try CallGraph &g= getAnalysis<CallGraph>, but it prints the same error and doesn't work as expected. Antony Yu Justin Holewinski-2 wrote > Sorry for the delay. Yeah, that error message is a bit confusing. What's > happening is

You shouldn't rely on that, its an implementation detail. Instead, you can trace back to the original Function object and check for kernel metadata. See http://llvm.org/docs/NVPTXUsage.html#marking-functions-as-kernels On Tue, Jun 25, 2013 at 11:09 AM, Antony Yu <swpenim at gmail.com> wrote: > Oops! No need of Call Graph! > In fact, what I want to do is to find which function

I write my pass in a mix way of NVPTXAllocaHoisting, NVPTXSplitBBatBar and transforms/Hello. The following is part of the codes: in NVPTXTargetMachine.cpp bool NVPTXPassConfig::addPreEmitPass() { addPass(createTest()); return false; } in NVPTXTest.h namespace llvm{

for ARM constant islands and Mips constant islands, the constant islands pass is registered as an addPreEmitPass. for mips at least, it ends of up getting called twice by the pass manager. why is that?

I try to use INITIALIZE_PASS instead of RegisterPass<> to register my pass, though I don't understand what's their difference and how it works because its documents doesn't exist. But it still doesn't work. Parts of my codes is as follows: in NVPTXTest.h namespace llvm { void initializeNVPTXTestPass(PassRegistry &r); class NVPTXTest : public ModulePass { public:

Sorry for the delay. Yeah, that error message is a bit confusing. What's happening is that your pass sequence is invalid. Once the IR has been lowered to machine code, its too late to run LLVM IR passes (ModulePass, FunctionPass, CallGraphSCCPass, etc.). At that point, you need to run a Machine*Pass, e.g. MachineFunctionPass. If you need to run an IR level pass, you need to use

Hello, I want to write a modulePass in addPreEmitPass() for NVPTX, but I encounter an assertion failed when executing clang. Here is my error message. ==== Pass 'NVPTX Assembly Printer' is not initialized. Verify if there is a pass dependency cycle. Required Passes: llc: /home/pyyu/local/llvm/lib/IR/PassManager.cpp:637: void llvm::PMTopLevelManager::schedulePass(llvm::Pass*): Assertion

Thanks, that did it! Are there any plans to enable the loop vectorizer by default? From: Nadav Rotem [mailto:nrotem at apple.com] Sent: Wednesday, April 03, 2013 13:33 PM To: Nowicki, Tyler Cc: LLVM Developers Mailing List Subject: Re: Packed instructions generaetd by LoopVectorize? Hi Tyler, Try adding -ffast-math. We can only vectorize reduction variables if it is safe to reorder floating

Thanks for the reply, they were very helpful. Is it enough to prevent BBVectorize from packing together double precision instructions? If a non-clang frontend is used, such as ISPC, is it possible that the IR may contain packed double instruction? Tyler From: Cameron McInally [mailto:cameron.mcinally at nyu.edu] Sent: Thursday, February 21, 2013 6:39 PM To: Nowicki, Tyler Cc: Nadav Rotem; LLVM

I understand, but this sounds like legalization. Does every architecture trigger an overflow exception, as opposed to setting a bit? Perhaps it makes more sense to do this in the backends that trigger an overflow exception? I'm working on a modification for DIV right now in the x86 backend for Intel Atom that will improve performance, however because the *actual* operation has been replaced

On Wed, Jun 27, 2012 at 4:02 PM, Nowicki, Tyler <tyler.nowicki at intel.com> wrote: > Hi, > > > > I noticed that when dividing with signed 8-bit values the IR uses a 32-bit > signed divide, however, when unsigned 8-bit values are used the IR uses an > 8-bit unsigned divide. Why not use a 8-bit signed divide when using 8-bit > signed values? "sdiv i8 -128,

Hi Tyler, Try adding -ffast-math. We can only vectorize reduction variables if it is safe to reorder floating point operations. Thanks, Nadav On Apr 3, 2013, at 10:29 AM, "Nowicki, Tyler" <tyler.nowicki at intel.com> wrote: > Hi, > > I have a question about LoopVectorize. I wrote a simple test case, a dot product loop and found that packed instructions are