similar to: [LLVMdev] Tablegen strings

So, I have this small test program that I figured would cause no problems but want to test all the various data types and operations with my modified sparc backend. I've been working on LLVM for about 3 days now, so this might be a problem with not knowing enough yet, so thanks for bearing with me. The code that I based my example off of is compiled to LLVM-IR from: void

I have a simple test case that my code generator handles fine when using optimizations, but when I disable optimizations, It turns into a sequence of instructions that I can't figure out what to setup to get it to generate the correct code. The instructions in question are: %tmp1 = load float* %test ; <float> [#uses=1] %conv = fpext float %tmp1 to double ;

On Wed, Sep 10, 2008 at 2:35 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > Generating the following LLVM IR: > > define void @test_unary_op_anegate(float %x, float addrspace(11)* %result) > nounwind { > entry: > %neg = sub float -0.000000e+000, %x ; <float> [#uses=1] > store float %neg, float addrspace(11)* %result >

-----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Eli Friedman Sent: Wednesday, September 10, 2008 3:30 PM To: LLVM Developers Mailing List Subject: Re: [LLVMdev] Custom Lowering and fneg On Wed, Sep 10, 2008 at 2:35 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > Generating the following LLVM IR: > > define

I'm trying to write a store pattern that accepts both i32 and f32, however, when tablegen generates the code, it only generates the code for i32 only. def ADDR : ComplexPattern<i32, 2, "SelectADDR", [], []>; def MEM : Operand<i32> { let PrintMethod = "printMemOperand"; let MIOperandInfo = (ops GPR, GPR); } def global_st :

Also some missing _src()s and cosmetic changes. --- src/gallium/programs/galliumut/Makefile | 5 + .../programs/galliumut/gen_uureg_opcodes.sh | 29 +++ src/gallium/programs/galliumut/uureg.h | 196 ++++---------------- 3 files changed, 71 insertions(+), 159 deletions(-) create mode 100644 src/gallium/programs/galliumut/gen_uureg_opcodes.sh diff --git

On Sep 23, 2008, at 10:44 AM, Villmow, Micah wrote: > I’m trying to write a store pattern that accepts both i32 and f32, > however, when tablegen generates the code, it only generates the > code for i32 only. > > def ADDR : ComplexPattern<i32, 2, "SelectADDR", [], []>; > def MEM : Operand<i32> { > let PrintMethod = "printMemOperand";

Eli, I've been working on this for a few days and still haven't gotten this towork. I've attached my dags that you asked for, and even there it is turning the floating point instruction into an integer return value. IR code just for reference: -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Villmow, Micah Sent:

We are syncing to 2.9 and we are hitting an with our backend in VerifySDNode in SelectionDAG.cpp. The first assert here is failing assert(!isa<MemSDNode>(N) && "Bad MemSDNode!"); Now, this is new to 2.9 and I am trying to understand what is invalid about what I am generating. What I generate has worked fine from LLVM version 2.4 until now without causing any issues.

+1 for an explicit FNEG instruction, since as previously discussed, it has stricter requirements for what value may be returned by the operation. And strengthening the requirement on FSUB is not feasible when the values are variables rather than literals. That is: FSUB(-0.0, NaN) = either NaN *or* -NaN FSUB(-0.0, -NaN) = either NaN *or* -NaN FNEG(NaN) = -NaN FNEG(-NaN) = NaN On Tue, Sep 11,

On Tue, Sep 25, 2018 at 1:39 PM Sanjay Patel <spatel at rotateright.com> wrote: > I have 1 concern about adding an explicit fneg op to IR: > > Currently, fneg qualifies as a binop in IR (since there's no other way to > represent it), and we have IR transforms that are based on matching that > pattern (m_BinOp). With a proper unary fneg instruction, those transforms >

Do we really want to have fneg be the only instruction with guaranteed no side effects? That just sounds like a gotcha waiting to happen. Or it could result in horrible code depending on the architecture. I’m still leaning towards having both an intrinsic and an instruction, and if they happen to have the same behavior then that’s fine. If fneg is to be a special instruction with extra promises

Regarding non-IEEE targets: yes, we definitely support those, so we do have to be careful about not breaking them. I know because I have broken them. :) See the discussion and related links here: https://reviews.llvm.org/D19391 But having an exactly specified fneg op makes that easier, not harder, as I see it. Unfortunately, if a target doesn't support this op (always toggle the sign bit and

How can I prevent some nodes from being combined in DAGCombine.cpp? Maybe what I want to do below doesn't follow the philosophy of LLVM, but I'd like to know if there is any way to avoid node from being combined. TargetLowering::PerformDAGCombine() is only called if DAGCombiner cannot combine a specific node. It seems that there is no chance to stop it from combining a node. I need the

On Tue, Sep 25, 2018 at 7:37 PM Sanjay Patel <spatel at rotateright.com> wrote: > > > On Tue, Sep 25, 2018 at 2:28 PM Cameron McInally <cameron.mcinally at nyu.edu> > wrote: > >> On Tue, Sep 25, 2018 at 1:39 PM Sanjay Patel <spatel at rotateright.com> >> wrote: >> >>> I have 1 concern about adding an explicit fneg op to IR: >>>

I have no example side effects in hand. But LLVM targets a bunch of architectures, and who knows what the future holds. So it may be prudent to not promise too much so as to leave ourselves an escape hatch. Doesn’t LLVM target some chips that have floating point instruction sets that are not IEEE compliant? Can we be certain that no new LLVM target will ever have to jump through hoops to avoid

Well, yes, they are different operations. And, yes, this needs to be corrected. This wasn’t my point. It’s a given. I was getting at the _declared_ absence of side effects and what promises we make to anyone using the new fneg instruction. Is this a promise we want to make? From: Cameron McInally <cameron.mcinally at nyu.edu> Sent: Wednesday, September 26, 2018 2:30 PM To: Kevin Neal

I am trying to make some modifications to our code generator that will produce better code, but require adding new patterns. What I am trying to do is take a register/register pattern and change it to a register/immediate. So for example, I have this pattern: class ILFormat<ILOpCode op, dag outs, dag ins, string asmstr, list<dag> pattern> : Instruction { let Namespace =

On Wed, 29 Aug 2018 at 07:51, Cameron McInally via llvm-dev <llvm-dev at lists.llvm.org> wrote: > The current thinking is that FNEG(X) and FSUB(-0.0, X) are not the same operation when X is a NaN or 0. Do you mean denormals (when flushed) rather than 0 there? AFAIK it's OK for 0 itself. > So, the xforms in question should only be valid under Fast-Math conditions. We could

I don't see any controversy for the preliminary requirement of removing BinaryOperator::isFNeg() and friends, so start with that? That work may reveal other potential regressions that we can patch in advance too. Other than that, I think there's really only a question of do we want 1 or both of fneg and fneg_constrained (and if we choose both, then I assume we'd also add