similar to: [LLVMdev] Swapping function arguments in libcalls

Displaying 20 results from an estimated 4000 matches similar to: "[LLVMdev] Swapping function arguments in libcalls"

2010 Sep 04
6
[LLVMdev] Possible missed optimization?
Hello, while testing trivial functions in my backend i noticed a suboptimal way of assigning regs that had the following pattern, consider the following function: typedef unsigned short t; t foo(t a, t b) { t a4 = b^a^18; return a4; } Argument "a" is passed in R15:R14 and argument "b" is passed in R13:R12, the return value is stored in R15:R14. Producing the
2010 Jan 05
1
[LLVMdev] [PATCH] test-suite/libcalls: unbreak build
On Tue, Jan 05, 2010 at 04:43:33PM +0300, Gregory Petrosyan wrote: > 'make TEST=example' works, 'make TEST=jit' and 'make' work too. Any ideas about what is going wrong here? No idea why this stuff was there... Index: TEST.libcalls.Makefile =================================================================== --- TEST.libcalls.Makefile (revision 92512) +++
2010 Jan 05
2
[LLVMdev] [PATCH] test-suite/libcalls: unbreak build
On Tue, Jan 05, 2010 at 10:05:21AM -0800, Chris Lattner wrote: > looks like some lines got moved, fixed on mainline, thanks. Not really fixed :-) Please commit this: Index: TEST.libcalls.Makefile =================================================================== --- TEST.libcalls.Makefile (revision 92749) +++ TEST.libcalls.Makefile (working copy) @@ -23,10 +23,10 @@
2010 Jan 05
0
[LLVMdev] [PATCH] test-suite/libcalls: unbreak build
On Jan 5, 2010, at 6:22 AM, Gregory Petrosyan wrote: > On Tue, Jan 05, 2010 at 04:43:33PM +0300, Gregory Petrosyan wrote: >> 'make TEST=example' works, 'make TEST=jit' and 'make' work too. Any >> ideas about what is going wrong here? > > No idea why this stuff was there... looks like some lines got moved, fixed on mainline, thanks. -Chris >
2010 Jan 05
0
[LLVMdev] [PATCH] test-suite/libcalls: unbreak build
Doh, thanks, done. -Chris On Jan 5, 2010, at 11:27 AM, Gregory Petrosyan wrote: > On Tue, Jan 05, 2010 at 10:05:21AM -0800, Chris Lattner wrote: >> looks like some lines got moved, fixed on mainline, thanks. > > Not really fixed :-) Please commit this: > > Index: TEST.libcalls.Makefile > =================================================================== > ---
2019 Jun 11
3
How to tell LLVM to treat Commutable library calls as such, for example multiplication?
A few library calls are commutable by definition, for example multiplications. I defined them as LibCalls for my architecture. However, I found that arguments are always passed in the order they are generated by Clang thus missing possible optimisations. For example, the following IR code ; Function Attrs: minsize norecurse nounwind optsize readnone define dso_local i16 @multTest(i16 %a, i16
2010 Jan 05
1
[LLVMdev] [PATCH] test-suite/libcalls: unbreak build
On Tue, Jan 05, 2010 at 11:42:10AM -0800, Chris Lattner wrote: > Doh, thanks, done. LOL. Next patch should be titled 'really really really fix this' :-) Please apply the last part of the diff, too: Index: TEST.libcalls.Makefile =================================================================== --- TEST.libcalls.Makefile (revision 92757) +++ TEST.libcalls.Makefile (working copy) @@
2012 Jan 09
0
[LLVMdev] libcalls for shifts
Hi, You're describing the exact same set of requirements for ARM - 64-bit loads and stores (LDRD, STRD) and multiplications but not shifts, adds, subtracts or anything else. ARM uses 32-bits as the largest possible type, and legalizes everything down to 32-bits. Why don't you do the same? Cheers, James -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu
2012 Jul 14
2
[LLVMdev] Issue with Machine Verifier and earlyclobber
Hello Jakob, I'm still getting the error, I can give you any other debug info you need. I haven't pasted the regalloc debug info here because it is quite huge, but if you tell me what specific details you need I will include them. Thanks for your help! 2012/7/14 Jakob Stoklund Olesen <stoklund at 2pi.dk> > > On Jul 14, 2012, at 10:09 AM, Borja Ferrer <borja.ferav at
2013 Jan 07
2
[LLVMdev] LLVM ERROR: ran out of registers during register allocation
Hello Jakob, Did you get a chance to take a look into this, and if not, can you do it when you get some spare time? Thanks! 2012/12/19 Borja Ferrer <borja.ferav at gmail.com> > We did something like this back when the register allocator couldn't split >> live ranges. >> > > Yes, I remember the isWinToJoinCrossClass() function, removed here: > >
2012 Jul 15
0
[LLVMdev] Issue with Machine Verifier and earlyclobber
Jakob, one more hint, I've placed some asserts around the code you added and noticed that the InlineSpiller::insertReload() function is not being called. 2012/7/14 Borja Ferrer <borja.ferav at gmail.com> > Hello Jakob, > > I'm still getting the error, I can give you any other debug info you need. > I haven't pasted the regalloc debug info here because it is quite
2013 Jan 07
0
[LLVMdev] LLVM ERROR: ran out of registers during register allocation
On Jan 7, 2013, at 4:58 AM, Borja Ferrer <borja.ferav at gmail.com> wrote: > Hello Jakob, > > Did you get a chance to take a look into this, and if not, can you do it when you get some spare time? It's not likely I'll have time to look at this in the near future. I'd recommend you do it yourself. /jakob > 2012/12/19 Borja Ferrer <borja.ferav at gmail.com>
2009 Apr 30
0
[LLVMdev] Declarations for libcalls.
Our assembler requires that the external functions used in a module should explicitly be declared using "extern" directive. The llvm libcall infrastructure doesn't keep a list of libcalls made for the module, though they are available as part of the list of all external symbols used by the module. Is it a good idea to keep the list of libcalls separate? - Sanjiv
2010 Jan 05
2
[LLVMdev] libcalls test fails to run
This is what I get while trying to run 'make TEST=libcalls' in the top dir of test-suite: make[1]: Entering directory `/home/gregory/thesis/llvm/projects/test-suite/SingleSource' make[2]: Entering directory `/home/gregory/thesis/llvm/projects/test-suite/SingleSource/UnitTests' make[3]: Entering directory
2013 Dec 20
2
[LLVMdev] Commutability of X86 FMA3 instructions.
Hi all, The 213 variant of the FMA3 instructions is currently marked commutable (see X86InstrFMA.td). Is that safe? According to the ISA the FMA3 instructions aren't commutable for non-numeric results, so I'd have thought commuting this would only be valid in fast-math mode? For the curious, the reason that I'm asking is that we currently always select the 213 variant, but this
2012 Jan 09
2
[LLVMdev] libcalls for shifts
>> Yes, well, i64 is a legal type, that's how it is. However, i64s are >> always stored in two 32-bit registers and in some cases need complicated >> instruction patterns for easy things (such as add, sub and so on) that >> basically simulate the i64 behaviour with a sequence of i32 >> instructions. > I think you're misunderstanding what it means for a type
2013 Dec 20
0
[LLVMdev] Commutability of X86 FMA3 instructions.
Hi Lang, Unfortunately, I don't have an answer on the commutability question, but I wanted to let you know that I filed a bug on this: http://llvm.org/bugs/show_bug.cgi?id=17229 This also shows a memory operand variant of the fma that you may want to consider in your patch and testcases. Thanks! On Thu, Dec 19, 2013 at 10:45 PM, Lang Hames <lhames at gmail.com> wrote: > Hi all,
2013 Jan 09
2
[LLVMdev] LLVM ERROR: ran out of registers during register allocation
Ok, I've found that marking tiny live intervals as not spillable inside VirtRegAuxInfo::CalculateWeightAndHint is not playing nicely with very constrained regclasses, in my case a regclass composed of only one register. As a workaround, instead of marking them as not spillable, I've marked them with a very high spill cost and the regalloc is able to compile the function with good code
2012 Jan 10
0
[LLVMdev] libcalls for shifts
Johannes, Try a custom lowering of the 64bit shift instructions and then in the Lower[SRL|SHL|SRA] function, generate a call instruction to the function you want. Micah > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Johannes Birgmeier > Sent: Sunday, January 08, 2012 2:38 AM > To: llvmdev at cs.uiuc.edu
2016 Jan 28
4
[RFC] Canonicalize libcalls to intrinsics
Hi, I would like to propose that when available, if a C builtin function has an equivalent llvm intrinsic, that the intrinsic be the preferred form. The equivalent clang __builtin should emit the intrinsic, and SimplifyLibCalls should replace calls with the intrinsic. For context, this came up on an old review thread: http://reviews.llvm.org/D5896 There are a few motivations for this: 1.