similar to: TwoAddressInstructionPass bug?

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, On SystemZ there are a set of "access registers" that can be copied in and out of 32-bit GPRs with special instructions. These instructions can only perform the copy using low 32-bit parts of the 64-bit GPRs. As reported and discussed at https://bugs.llvm.org/show_bug.cgi?id=44254, this is currently broken due to the fact that the default register class for 32-bit integers is

Hi, (This only concerns MISNeedChainEdge(), and is separate from D8705) I found out that the MIScheduler (pre-ra) could not handle a simple test case (test/CodeGen/SystemZ/alias-01.ll), with 16 independent load / add / stores. The buildSchedGraph() put too many edges between memory accesses, because 1) There was no implementation of areMemAccessesTriviallyDisjoint() for SystemZ. 2) Type

Hi, Using llvm-stress, I got a crash after Post-RA pseudo expansion, with machine verifier. A 128 bit register %vreg233:subreg_l32<def,read-undef> = LLCRMux %vreg119; GR128Bit:%vreg233 GRX32Bit:%vreg119 gets spilled: %vreg265:subreg_l32<def,read-undef> = LLCRMux %vreg119; GR128Bit:%vreg265 GRX32Bit:%vreg119 ST128 %vreg265, <fi#10>, 0, %noreg;

Hi, SystemZ supports @llvm.ctlz.i64() natively with a single instruction (FLOGR), and lesser bitwidth versions of the intrinsic are promoted to i64. For some reason, this leads to unfolded additions of constants as shown below: This function: define i16 @fun(i16 %arg) {   %1 = tail call i16 @llvm.ctlz.i16(i16 %arg, i1 false)   ret i16 %1 } ,gives this optimized DAG as input to instruction

Hi, I wonder if anyone has any comment on a patch like: diff --git a/lib/CodeGen/SelectionDAG/InstrEmitter.cpp b/lib/CodeGen/SelectionDAG/InstrEmitter.cpp index 65ee3816f84..4780f6f0e59 100644 --- a/lib/CodeGen/SelectionDAG/InstrEmitter.cpp +++ b/lib/CodeGen/SelectionDAG/InstrEmitter.cpp @@ -243,18 +243,21 @@ void InstrEmitter::CreateVirtualRegisters(SDNode *Node,      if (!VRBase &&

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, It seems to me that the TwoAddressInstructionPass::runOnMachineFunction method has some problems when the tied destination register has a subReg. The two changes below improves the situation for me but I'm all new to this so I'm not sure how it's supposed to work. I'm running on 2.9. Any comments? @@ -1172,12 +1172,20 @@ bool

> -----Ursprüngliche Nachricht----- > Von: Prof Brian D Ripley > Gesendet am: Tuesday, March 07, 2000 11:30 AM > An: dtrenkler@nts6.oec.uni-osnabrueck.de > Cc: r-devel@stat.math.ethz.ch; R-bugs@biostat.ku.dk > Betreff: Re: [Rd] R-crash using cut-and-paste (PR#472) > > On Tue, 7 Mar 2000 dtrenkler@nts6.oec.uni-osnabrueck.de wrote: > > > Dear R-Team, > >

Dear guys, I need help fixing a little piece of code. I have a pass that I really want to execute after the TwoAddressinstructionPass. But if I write "AU.addRequiredID(TwoAddressInstructionPassID);" in my pass' getAnalysisUsage, I end up getting the infamous: PassManagerT.h:387: failed assertion `getAnalysisOrNullUp(P) &&

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

Hi, I would like to access the AsmPrinter MachineFunctionPass during compilation in order to do alternative dumping of instructions, instead of using MI->dump(), which can get a bit messy. Is there any way to access this object or the assembler strings? It seems that even these strings / methods are not available through any static methods. Does it exist during the whole compilation or is it

Hi, I have a question regarding this method, as i have discovered a case where it seems very far from 'strict'. I had two MI's, A and B, where A is !isSafeToMove(): A B TwoAddress pass changes the order to B A , as it reschedules the LastKill MI (B). Is this a bug in TwoAdress, or is it the case that isSafeToMove() is weaker than isSchedulingBoundary() so that these indirect

Hi, I'm trying to fit a smooth line in a plot(y ~ x) graph. x is continuous variable y is a proportion of success in sub-samples, 0 <= y <= 1, from a Monte Carlo simulation. For each x there may be several y-values from different runs. Each run produces several sub-samples, where "0" mean no success in any sub- sample, "0.5" means success in half of the

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? Is there anything that makes it troublesome after RA has been performed? Could you tell me if the transformations below are correct? 1) a := b op c --> a := b --> a := b a := a op c a

> > 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. > Is there anything that makes it troublesome after RA > has been performed? Do you

On Tue, Mar 22, 2016 at 5:13 PM Eric Christopher wrote: > I think we can probably go ahead and throw this up on Phabricator for > review. I'd probably bring in Matthias for review as well. > > Thanks! > > -eric > (Follow up on the discuss in IRC) I tried to bridge PPC backend and commuteInstruction, not sure if correctly, but here I got some non-optimal results: in 12

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

On Mon, 26 Jun 2006, Fernando Magno Quintao Pereira wrote: > The problem is that, after the TwoAddressInstructionPass is used, the > code is no longer in SSA form, and my register allocator rely on > some SSA properties. I am using the Spiller in VirtRegMap.* to generate > the code, but the incorrect mapping still happens when I invoke the > setReg() method directly on machine