similar to: [LLVMdev] Problem in TwoAddressInstructionPass::runOnMachineFunction regarding subRegs

Greets, When merging lots of subindexes in batches like so: xapian-compact -m idx1 idx2... dstidx Errors such as: xapian-compact: DatabaseError: Error reading block 0: got end of file present a problem since it does not provide the offending path name (of the broken index) for easy identification/removal in automated/batch scenarios (the way DatabaseOpeningError:.... does, eg). The only way

Good Morning, all, I stumbled across a couple o' three of curious things in the LLVM code. I'm too new to this to know whether these are functioning correctly or not. Guidance would be appreciated. Perhaps it is something I have done wrong, but my executions of llc are creating two FPPassManager objects (that run different sets of passes). FPPassManager contains a static char ID

Hi Jonas, Thanks for bringing that up. > On Nov 30, 2017, at 4:04 AM, Jonas Paulsson via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi, > > we are in the midst of an interesting work that begun with setting 'guessInstructionProperties = 0' in the SystemZ backend. We have found this to be useful, and discovered many instructions where the hasSideEffects flag

Hi, we are in the midst of an interesting work that begun with setting 'guessInstructionProperties = 0' in the SystemZ backend. We have found this to be useful, and discovered many instructions where the hasSideEffects flag was incorrectly set while it actually shouldn't. The attached patch and test case triggers an assert in TwoAddress.  (bin/llc ./tc_TwoAddr_crash.ll

Hi, I have cases of instruction pairs, where one is cheaper 2-address, and the other 3-address. I would like to select the 2-addr instruction during isel, but use the 3-addr instruction to avoid a copy if possible. I find that TwoAddressInstructionPass::isProfitableToConv3Addr() is only checking for the case of a physreg copy, and so leaves the majority of cases as they are (2-address). I

A similar setting occurs with ARM Thumb code which for many instructions has a short 2-address encoding and a longer 3 address form. As far as I know this is done by selecting the 3 address form and rewriting them to 2-address after register allocation where possible. See lib/Target/ARM/Thumb2SizeReduction.cpp. - Matthias > On Sep 29, 2015, at 2:22 PM, Quentin Colombet via llvm-dev

Hi, I'm trying to complete the lowering for a new microcontroller. I'm using LLVM 3.8. For now this lowering crashes on 'Store' node, which is actually not yet defined. I've tried to map the ISel 'Store' node to architecture specific instructions. I've define the following semantic to my architecture specific instructions: def MOVSUTO_SU_rr :

Hi, Assume I define registers R0...R15 and two register classes RegA and RegB. RegA contains R0 to R7 while RegB contains R0 to R15. Then I check the machine instruction, it seems that in some cases, the %vreg0 belongs to RegB; in other cases %vreg1 belongs to RegA_RegB. Can you tell me how TableGen decides which is which? At first, I guess &verg0 will be assigned by R8 to R15 only so that

On Oct 2, 2013, at 11:48 PM, Evan Cheng <evan.cheng at apple.com> wrote: > The two address pass is only concerned about register pressure. It sounds like it should be taught about profitability. In cases where profitability can only be determined with something machinetracemetric then it probably should live it to more sophisticated pass like regalloc. > > In this case, we

Hi, I'm try to lower the store LLVM-IR instruction as per the following LLVM IR program: *** IR Dump After Module Verifier *** define void @storeloadi32() { %ptr = alloca i32 store volatile i32 12, i32* %ptr ret void } The target instruction is associated to the store like this: def MOVSUTO_A_iSLr : CLPFPU_A_iSLr<0b1000001101,

> > Thank you Chris. I will try to implement the TwoAddress pass to run on > > machine code. Why it has not been originally implemented to run on > > machine code? > > I'm not sure what you mean. It definitely does run on machine code. I was thinking that it only transformed instructions with virtual registers because of this code in the TwoAddressInstructionPass.cpp:

On Mon, 26 Jun 2006, Fernando Magno Quintao Pereira wrote: >>> Thank you Chris. I will try to implement the TwoAddress pass to run on >>> machine code. Why it has not been originally implemented to run on >>> machine code? >> >> I'm not sure what you mean. It definitely does run on machine code. > > I was thinking that it only transformed

This sounds like llvm.org/pr13320. On 17 September 2013 18:20, Bader, Aleksey A <aleksey.a.bader at intel.com> wrote: > Hi all. > > > > I’m looking for an advice on how to deal with inefficient code generation > for Intel Nehalem/Westmere architecture on 64-bit platform for the attached > test.cpp (LLVM IR is in test.cpp.ll). > > The inner loop has 11 iterations

You may have noticed Andy and me committing TableGen patches for "register units". I thought I'd better explain what they are. Some targets have instructions that operate on sequences of registers. I'll use ARM examples because it is the most notorious. ARM has, for example: vld1.64 {d1, d2}, [r0] The instruction loads two d-registers, but they must be consecutive. ARM also

Hi, I'm having trouble using virtual register in the X86 backend. I implemented a new intrinsic and I use a custom inserter. The goal of the intrinsic is to set the content of the stack to zero at the end of each function. Here is my code: MachineBasicBlock * X86TargetLowering::EmitBURNSTACKWithCustomInserter( MachineInstr *MI, MachineBasicBlock

Hi, Thx for your help... Here is the IR code: ; ModuleID = 'foo_bar.c' target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128" target triple = "x86_64-unknown-linux-gnu" @.str = private unnamed_addr constant [6 x i8] c"MAIN\0A\00", align 1 ; Function Attrs: nounwind uwtable define i32 @main(i32 %argc, i8** %argv) #0 { entry: %retval = alloca i32,

The two address pass is only concerned about register pressure. It sounds like it should be taught about profitability. In cases where profitability can only be determined with something machinetracemetric then it probably should live it to more sophisticated pass like regalloc. In this case, we probably need a profitability target hook which knows about lea. We should also consider disabling

Hi all. I'm looking for an advice on how to deal with inefficient code generation for Intel Nehalem/Westmere architecture on 64-bit platform for the attached test.cpp (LLVM IR is in test.cpp.ll). The inner loop has 11 iterations and eventually unrolled. Test.lea.s is the assembly code of the outer loop. It simply has 11 loads, 11 FP add, 11 FP mull, 1 FP store and lea+mov for index

Ø It would be good to check that this maps correctly onto computeRegisterLiveness: there's a bug in analyzePhysReg and I think other parts of the code base are slightly wrong or will become slightly wrong as well :-( Yes, I agree. I will also have to look into all other users of analyzePhysReg as well. There are surprisingly few users of either computeRegisterLiveness or analyzePhysReg.

>-----Original Message----- >From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of >Sanjoy Das via llvm-dev >Sent: Thursday, December 03, 2015 11:16 PM >To: Quentin Colombet <qcolombet at apple.com> >Cc: llvm-dev at lists.llvm.org >Subject: Re: [llvm-dev] analyzePhysReg question > >I think this is related to PR25033: