similar to: Proposed new min and max intrinsics

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

Hello Evan and Robert I have been investigating the unexpected test failures from the ARM nightly builders in order to get a better picture why the ARM backend don't pass the whole testsuite: I have run the failing tests manually on my arm board and can now categorize most of the thirteen unexpected CodeGen failures in four categories: 1. llvm don't lower MVT::i64 properly on arm

Hi Xerxes, > 4. softfloat related errors > http://labb.zafena.se/shark-testing/llvmARMCodeGenFailures200904/softenfloat_Do_not_know_how_to_soften_the_result_of_this_operator/ > example: > > root at overo:/home/xerxes/llvm-test/fail/CodeGen/softenfloat# llvm-as < 2007-11-19-VectorSplitting.ll | llc > SoftenFloatResult #0: 0x614e00: f32 = undef > llc:

Duncan Sands skrev: > Hi Xerxes, > > >> 4. softfloat related errors >> http://labb.zafena.se/shark-testing/llvmARMCodeGenFailures200904/softenfloat_Do_not_know_how_to_soften_the_result_of_this_operator/ >> example: >> >> root at overo:/home/xerxes/llvm-test/fail/CodeGen/softenfloat# llvm-as < 2007-11-19-VectorSplitting.ll | llc >>

LLVM ARM v6 backend is in fairly good shape. Even the JIT passes nearly the entire llvm test suite. There are some known missing bits: 1. Exception handling 2. Atomic Not sure: 3. Debugging support (should be trivial to hook up if it's not done) Also the thumb backend is not awesome. Its performance is not great. Evan On Apr 1, 2009, at 6:34 AM, Robert Schuster wrote: > Hi, > the

Hi, the ARM backend lacks some stuff like support for atomic intrinsics. I learned the hard way (crash). Lately I was told that the ARM backend of LLVM is generally in its early stages of development. I would like to know more about this. Which stuff is missing, known to be unstable and the like. Thanks in advance for taking the time. Regards Robert -------------- next part -------------- A

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

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

Do we have a test that exercises ISD::FP_ROUND_INREG in SelectionDAGLegalize::ExpandNode()? I ask because I'm working on code that reuses that block in the switch and I'm trying to write a test. But I'm having trouble and would like to see what a working test for the existing code looks like. A quick grep of the tree doesn't show anything. Ideas? -- Kevin P. Neal

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

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

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

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

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[] = {

On 3/16/2016 12:53 PM, Rail Shafigulin wrote: > > On Wed, Mar 16, 2016 at 10:39 AM, Krzysztof Parzyszek via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > On 3/16/2016 12:36 PM, Krzysztof Parzyszek via llvm-dev wrote: > > If the action is "Expand", which will convert the operation into > > >

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.

On Wed, Mar 17, 2010 at 4:57 PM, Sergey Yakoushkin <sergey.yakoushkin at gmail.com> wrote: > Thanks, yes, I'm facing the same issue. > > Hm... seems there are no simple fixes. > I have to do one more i64 mul implementation to workaround aggressive > optimizations. > Is that correct? Is this the only way? This shouldn't be necessary, IMO. If you were going to

On Fri, 23 Mar 2012 09:50:12 +0100 Ivan Llopard <ivanllopard at gmail.com> wrote: > Hi Finkel, > > Le 23/03/2012 05:50, Hal Finkel a écrit : > > The PowerPC backend on PPC64 for non-Darwin (SVR4 ABI) systems > > currently has a problem handling integer types smaller than 64 bits. > > This is because the ABI specifies that these types are > > zero-extended

On 20/01/13 19:20, Caldarale, Charles R wrote: [...] > That's because there is no llvm.ceil.* intrinsic defined in include/llvm/Intrinsics.td for 3.2 Ah. Yes, that would explain it... does this mean that I can rely on all the intrinsics listed existing for the common types (int, float, double)? Or should I be trying to follow the libc call route? I've noticed that llc is successfully