similar to: Early legalization pass ? Doing early legalization in an existing pass ?

I may be wrong here, but legalizing early seems like something that is more likely to prevent optimizations than it is to encourage them. But I guess I don't follow why things like TTI, TII and TLI queries don't suffice for this. CodeGenPrepare will break this sequence up. I would imagine that if the target returns false for isCheapToSpeculateCtlz() and false for canInsertSelect(), the

These instructions are prefix selected flavors of bsf and bsr respectively, and hence the presences of the F3 prefix must be handled in the emulation code in order to avoid running into problems on newer CPUs. Signed-off-by: Jan Beulich <jbeulich@suse.com> --- a/xen/arch/x86/x86_emulate/x86_emulate.c +++ b/xen/arch/x86/x86_emulate/x86_emulate.c @@ -1058,6 +1058,9 @@ static bool_t vcpu_has(

El 03/05/12 12:19, Miroslav Lichvar escribi?: > Hi Josh, > > nice to see you here again. > > On Wed, Apr 25, 2012 at 04:26:05PM -0700, Josh Coalson wrote: >> (Jumping in again, maybe at the wrong point since this doesn't seem >> to involve encoding, but here goes.) >> >> Miroslav's patches have always been high-quality for sure. But >>

On 15 Jan 2010, at 18:03, Chris Lattner wrote: > On Jan 14, 2010, at 10:13 PM, David Conrad wrote: > >> Other targets that I know of that could potentially benefit from >> this optimization being global (that have a clz and bitreverse >> instruction but not ctz) are AVR32 and C64x, neither of which llvm >> has backends for yet. > > When/if another

Hi Eli, Thanks for pointing to the CTLZ_ZERO_UNDEF “LibCall” implementation. I have not it in the version that I am currently using, so it’s nice to know that it’s implemented now. Incidentally, the CTLZ… implementation is IDENTICAL to what I am proposing for the Shifts. This is not just adding support for “out-of-tree-targets”, but giving consistency to the fact that we have perfectly defined

They are all Alpha/PowerPC codegen related. Running /usr/home/jeffc/llvm/obj/../test/Regression/CodeGen/Alpha/dg.exp ... FAIL: /usr/home/jeffc/llvm/obj/../test/Regression/CodeGen/Alpha/2005-07-12-TwoMallocCalls.ll: NODE: 0x8582a40: i32,ch = CopyFromReg 0x8582980:1, 0x85829c0 Abort trap (core dumped) FAIL: /usr/home/jeffc/llvm/obj/../test/Regression/CodeGen/Alpha/bsr.ll: NODE: 0x85823c0:

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

On Jan 15, 2010, at 11:37 AM, Richard Osborne wrote: > > On 15 Jan 2010, at 18:03, Chris Lattner wrote: > >> On Jan 14, 2010, at 10:13 PM, David Conrad wrote: >> >>> Other targets that I know of that could potentially benefit from >>> this optimization being global (that have a clz and bitreverse >>> instruction but not ctz) are AVR32 and C64x,

On Jan 15, 2010, at 2:52 PM, Jim Grosbach wrote: > > On Jan 15, 2010, at 11:37 AM, Richard Osborne wrote: > >> >> On 15 Jan 2010, at 18:03, Chris Lattner wrote: >> >>> On Jan 14, 2010, at 10:13 PM, David Conrad wrote: >>> >>>> Other targets that I know of that could potentially benefit from >>>> this optimization being

LLVM appears to support Library functions for ISD::SRA ,ISD::SHL, and ISD::SRL, as they are properly defined in RuntimeLibCalls.def. The library functions defined in RuntimeLibCalls.def (among others) are these: HANDLE_LIBCALL(SRA_I16, "__ashrhi3") HANDLE_LIBCALL(SRA_I32, "__ashrsi3") HANDLE_LIBCALL(SRA_I64, "__ashrdi3") However, setting

Developers, As part of PR411, I have made several of the intrinsic functions non- overloaded. While the assembler and bytecode reader are backwards compatible, front-end writers should start using the non-overloaded versions of the intrinsics. The llvm-gcc has already been updated to generate the new intrinsic names. Other front-ends will start seeing warnings about the names of intrinsics that

Hi Eli, First of all, please I would appreciate that you try to not confuse my limited use of English with stupidity or lack or criteria in other subjects. I’m not English native, so please keep that in mind. You have been significantly helpful in the recent past so please keep on. Interestingly, you made a mention of a related but not identical issue. It is true that most (or all) processors

Per subject, this patch adding an additional pass to handle vector operations; the idea is that this allows removing the code from LegalizeDAG that handles illegal types, which should be a significant simplification. There are still some issues with this patch, but does the approach look sane? -Eli -------------- next part -------------- Index: lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp

Are you looking for something other than calling __builtin_clz from c++ or calling @llvm.ctlz.* instrinsic from IR? I don't think we have anything that will auto converting a loop to ctlz or anything like that. We only seem to have a detection for popcount loops. On Thu, Aug 15, 2013 at 9:01 PM, reed kotler <rkotler at mips.com> wrote: > Does anyone know some simple c/c++ code or

<div> </div><div><div><p>Carry-less multiplication[1] instructions exist (at least optionally) on many architectures: armv8, RISC-V, x86_64, POWER, SPARC, C64x, and possibly more.</p><p>This proposal is to add a <code>llvm.clmul</code> instruction. Or if that is contentious, <code>llvm.experimental.bitmanip.clmul</code> instruction.

Does anyone know some simple c/c++ code or .ll code which will cause this ctlz pattern to be emitted? Tia. Reed

05.07.2020, 05:22, "Roman Lebedev" <lebedev.ri at gmail.com>: > On Sun, Jul 5, 2020 at 12:18 PM Shawn Landden via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >>  Carry-less multiplication[1] instructions exist (at least optionally) on many architectures: armv8, RISC-V, x86_64, POWER, SPARC, C64x, and possibly more. >> >>  This proposal is to add a

--- src/libFLAC/include/private/bitmath.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/libFLAC/include/private/bitmath.h b/src/libFLAC/include/private/bitmath.h index 42ce639..e5c7695 100644 --- a/src/libFLAC/include/private/bitmath.h +++ b/src/libFLAC/include/private/bitmath.h @@ -74,7 +74,7 @@ static inline unsigned int FLAC__clz_uint32(FLAC__uint32 v) { /* Never

rutine -> routine Also MSVC complains that FLAC__uint32* (unsigned int*) is not of the same type as unsigned long* --- a\src\libFLAC\include\private\bitmath.h 2013-08-13 13:30:24.000000000 +0400 +++ b\src\libFLAC\include\private\bitmath.h 2013-08-14 10:20:51.484053700 +0400 @@ -78,12 +78,12 @@ return _bit_scan_reverse(v) ^ 31U; #elif defined(__GNUC__) && (__GNUC__ >= 4 ||

> On 2 Jul 2018, at 15:13, Matthias Braun via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I had similar gripes with unit testing machine function stuff. I personally would have preferred to create more tests based on a tool like llc rather than pushing more on the unit test side. Anyway I tried to push https://reviews.llvm.org/D48850 <https://reviews.llvm.org/D48850> in