similar to: Test for ISD::FP_ROUND_INREG?

On Thu, 11 Oct 2018 at 00:28, Thomas Lively via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I just wanted to bump this to see if anyone has any input. I would really like to get these landed soon if there are no objections. Hi Thomas, With ISD::FMINNAN and ISD::FMAXNAN now easy to produce for any target due to these newly exposed intrinsics, I think these nodes should be handled

Thanks, Andy. I'm not sure how to solve that or my case given the DAG's basic-block limit. Probably CodeGenPrepare or SelectionDAGBuilder...or we wait until after isel and try to split it up in a machine instruction pass. I filed my example here: https://bugs.llvm.org/show_bug.cgi?id=33013 Feel free to comment there and/or open a new bug for the FP_TO_UINT case. On Thu, May 11, 2017 at

Sounds like the select lowering issue is definitely separate from the FENV work. Is there a bug report with a C or IR example? You want to generate compare and branch instead of a cmov for something like this? int foo(float x) { if (x < 42.0f) return x; return 12; } define i32 @foo(float %x) { %cmp = fcmp olt float %x, 4.200000e+01 %conv = fptosi float %x to i32 %ret = select

In http://reviews.llvm.org/D8713, I added the 64bit integer store ("std") and load ("ldd") instructions for 32bit sparc. But now I need codegen to know how to emit them, and am not sure the best way to go about teaching the backend that 64bit integers can be used natively, but only for loads and stores. (I originally wrote an earlier draft of question in the review but it

Alex, After looking into this a bit, it looks to me like the best thing to do for targets that do not natively support ISD::MINIMUM and ISD::MAXIMUM would be to fall back to a libcall, since implementing these operations in terms of existing operations is actually rather complicated. Do you think it would make sense to add builtin functions to compiler-rt to implement these operations, or is

Hi Andy, I’m interested to try out your patches… I understand the scope of FENV_ACCESS is relatively wide, however I’m still curious if you managed to figure out how to prevent the SelectionDAGLegalize::ExpandNode() FP_TO_UINT lowering of the FPToUI intrinsic from producing the predicate logic that incorrectly sets the floating point accrued exceptions due to unconditional execution of the

Thanks, indeed it was on the LegalizeDAG.cpp and the information proved very useful. I also realized that the customization, promotion or expansion will occur whenever any operand, with the same type as the type specified on the second argument (MVT) of setOperationAction function, appears. (Correct me if I'm wrong). The second doubt I have regards instruction matching. When I define a

Hi James, Jim If you *really* want this to work in selection DAG then there is a solution, but its not pretty. First make i64 not be legal. Then, assuming the regclass you gave has some subregs, you can give load/store a custom legalisation where you change the i64 to MVT::Untyped. So something like this for ISD::STORE: SDValue ValueToBeStored = St.getOperand(…) auto SeqOps[] = {

sqrtf is detected by code in SelectionDAGBuilder.cpp. This gets turns into a FSQRT ISD node type that the target can handle just like any other ISD node. If the target doesn't mark ISD::FSQRT as Legal or Custom then ExpandNode in LegalizeDAG.cpp turns it back into a sqrtf libcall. On Sun, Jan 20, 2013 at 11:34 AM, David Given <dg at cowlark.com> wrote: > On 20/01/13 19:20,

> This shouldn't be necessary, IMO. If you were going to implement it, > then the correct thing to do would be to have generic selection dag > lowering of large multiplies, which renders the library mostly > useless. In fact, I would prefer to avoid custom lowering for operations on large types. i64 will be rare in my case (embedded) and their performance is not an issue. I need

On Thu, Sep 6, 2012 at 10:56 AM, Michael LIAO <michael.hliao at gmail.com>wrote: > On Thu, Sep 6, 2012 at 10:02 AM, Reed Kotler <rkotler at mips.com> wrote: > > Here is the problem explained more. > > > > Normally there is a 64 bit register that is the result of certain > multiply > > and divide instructions. > > It's really 2 32 bit registers.

x <- "\u0663" y <- 3 x == y # FALSE rank(c(x, y)) # c(1.5, 1.5) -- http://had.co.nz/

No, I don't. Cheers, Gary Dale Johannesen wrote: > This looks OK to check in, do you have write access? > > On Aug 21, 2008, at 6:38 AMPDT, Gary Benson wrote: > > >Dale Johannesen wrote: > >>On Aug 19, 2008, at 7:18 AMPDT, Gary Benson wrote: > >>>I'm trying to implement llvm.memory.barrier on PowerPC. I've > >>>modelled my patch

Hi all, I'm trying to implement llvm.memory.barrier on PowerPC. I've modelled my patch (attached) on the implementation in X86, but when I try and compile my test file (also attached) with llc I get the error "Cannot yet select: 0x10fa4ad0: ch = MemBarrier 0x10fa4828, 0x10fa4c68, 0x10fa4be0, 0x10fa4be0, 0x10fa4be0, 0x10fa4be0". This presumably means my "membarrier"

Sorry, glad I'm in the right place. Before I start, I want to state that I'm a beginer and I'm trying to develop a backend by adapting an existent target to my platform. My first doubt is about the SelectionDAG and the TargetLowering class. When I use, for example: setOperationAction(ISD::ADD, MVT::i1, Promote); Is it correct to say that I'm promoting any operand used by the

Dale Johannesen wrote: > On Aug 19, 2008, at 7:18 AMPDT, Gary Benson wrote: > > I'm trying to implement llvm.memory.barrier on PowerPC. I've > > modelled my patch (attached) on the implementation in X86, but > > when I try and compile my test file (also attached) with llc I > > get the error "Cannot yet select: 0x10fa4ad0: ch = MemBarrier > >

I'm having some troubles implementing vector support to our custom backend It seems that llvm cannot emulate shuffle with extracts, inserts and builds? I've enabled vector registers with addRegisterClass(MVT::v2i32, TCE::V2I32RegsRegisterClass); addRegisterClass(MVT::v2f32, TCE::V2F32RegsRegisterClass); and created patterns for most vector instructions, including insert, extract and

I think it’s generally true that whenever branches can reliably be predicted branching is faster than a cmov that involves speculative execution, and I would guess that your assessment regarding looping on input values is probably correct. I believe the code that actually creates most of the transformation you’re interested in here is in SelectionDAGLegalize::ExpandNode() in LegalizeDAG.cpp. The

> On Apr 2, 2015, at 2:07 PM, Tom Stellard <tom at stellard.net> wrote: > > On Thu, Apr 02, 2015 at 01:35:55PM -0700, Pete Cooper wrote: >> Hi James, Jim >> >> If you *really* want this to work in selection DAG then there is a solution, but its not pretty. >> >> First make i64 not be legal. Then, assuming the regclass you gave has some subregs, you

On Mon, Jun 6, 2016 at 8:32 AM, Nemanja Ivanovic via llvm-dev <llvm-dev at lists.llvm.org> wrote: > It is not a keyword. It is a node defined in > include/llvm/Target/TargetSelectionDAG.td. You can likely find most of the > definitions you're wondering about there. > In terms of its purpose, perhaps someone can elaborate on that a bit more, > but there is no corresponding