search for: cttz

...ruction but not ctz) are AVR32 and C64x, neither of which llvm >> has backends for yet. > > When/if another target wants this, we could add a ISD::RBIT operation, > it doesn't need to be added at the llvm ir level, The XCore also has ctlz and bitreverse instructions and not cttz. At the moment in the XCore backend cttz is marked as legal and expanded to this pair of instructions in a pattern in the InstrInfo.td. -- Richard Osborne | XMOS http://www.xmos.com

...d in the front end. Here are the intrinsics that need to be changed: llvm.bswap -> llvm.bswap.i16, llvm.bswap.i32, llvm.bswap.i64 llvm.ctpop -> llvm.ctpop.i8, llvm.ctpop.i16, llvm.ctpop.i32, llvm.ctpop.i64 llvm.ctlz -> llvm.ctlz.i8, llvm.ctlz.i16, llvm.ctlz.i32, llvm.ctlz.i64 llvm.cttz -> llvm.cttz.i8, llvm.cttz.i16, llvm.cttz.i32, llvm.cttz.i64 llvm.isunordered -> llvm.isunordered.f32, llvm.isunordered.f64 llvm.sqrt -> llvm.sqrt.f32, llvm.sqrt.f64 Thanks, Reid. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type:...

Hi, On ARMv6T2 this turns cttz into rbit, clz instead of the 4 instruction sequence it is now. I'm not sure if adding RBIT to ARMISD and doing this optimization in the legalize pass is the best option, but the only better way I could think of doing it was to add a bitreverse intrinsic to llvm ir, which itself might not be t...

...and C64x, neither of which llvm >>> has backends for yet. >> >> When/if another target wants this, we could add a ISD::RBIT >> operation, >> it doesn't need to be added at the llvm ir level, > > The XCore also has ctlz and bitreverse instructions and not cttz. At > the moment in the XCore backend cttz is marked as legal and expanded > to this pair of instructions in a pattern in the InstrInfo.td. In that case, perhaps it makes sense to add it as an ISD::RBIT operation straight away. The rest of the patch looks good to me. -Jim

...m >>>> has backends for yet. >>> >>> When/if another target wants this, we could add a ISD::RBIT >>> operation, >>> it doesn't need to be added at the llvm ir level, >> >> The XCore also has ctlz and bitreverse instructions and not cttz. At >> the moment in the XCore backend cttz is marked as legal and expanded >> to this pair of instructions in a pattern in the InstrInfo.td. > > In that case, perhaps it makes sense to add it as an ISD::RBIT > operation straight away. Since only a couple of targets can...

On Jan 14, 2010, at 10:13 PM, David Conrad wrote: > Hi, > > On ARMv6T2 this turns cttz into rbit, clz instead of the 4 > instruction sequence it is now. > > I'm not sure if adding RBIT to ARMISD and doing this optimization in > the legalize pass is the best option, but the only better way I > could think of doing it was to add a bitreverse intrinsic to llvm...

Hi Roman, > That depends. > If there's LLVM intrinsic for it, then any normal optimization pass could do it. > In cttz's case it's mainly done in LoopIdiom pass. Oh yes. Thank you! Unfortunately several of the instructions of the bit manipulation extension don't seem to have an intrinsic already in LLVM. That will require to add some passes to the middle end. > Again, i'd say this is too broad...

...ion currently. I want to verify that if I add such an intrinsic, it would be illegal for any existing optimization pass to hoist the constant parameter. For example, if I add a target intrinsic llvm.foo that takes two parameters: i32 and i1, where the i1 parameter must be a constant (same as llvm.cttz), I want to verify that the following optimization is illegal without having to change any LLVM passes: Input: define i32 @f0(i32 %a, i1 %pred) { br i1 %pred, label %first, label %second first: %r0 = tail call i32 @llvm.foo.i32(i32 %a, i1 true) br label %end second: %r1 = tail call i32 @l...

...It takes two integer operands of the same width, and returns an integer with twice the width of the operands. (Is there a good reason to make these the same width, as all the other operations do even when it doesn’t really make sense for the mathematical operation–like multiplication or ctpop/ctlz/cttz?)</p><p>If the CPU does not have a dedication clmul operation, it can be lowered to regular multiplication, by using holes to avoid carrys.</p><p>==Where is clmul used?==</p><p>While somewhat specialized, the RISC-V manual documents many uses: [2]</p><p&...

On Fri, Jan 15, 2010 at 6:03 PM, Chris Lattner <clattner at apple.com> wrote: > > On Jan 14, 2010, at 10:13 PM, David Conrad wrote: > >> Hi, >> >> On ARMv6T2 this turns cttz into rbit, clz instead of the 4 >> instruction sequence it is now. >> >> I'm not sure if adding RBIT to ARMISD and doing this optimization in >> the legalize pass is the best option, but the only better way I >> could think of doing it was to add a bitreverse intri...

...RTLIB::SRA_I16, RTLIB::SRA_I16, RTLIB::SRA_I32, RTLIB::SRA_I64, RTLIB::SRA_I128)); I think this is a BUG by omission of necessary switch cases. Similarly, the following ISD codes ISD::CTTZ, ISD::CTLZ, ISD::CTPOP do not define any Library calls, despite LLVM being able to fully expand them into rather large code for targets that do not natively implement them. I regard this also as an omission/bug, because not all targets would benefit from the custom expansion of these ISD codes, whi...

Hi all, I'm currently working on the implementation for LLVM of the RISCV Bit Manipulation ISA extension described by Clifford Wolf in the following presentation: https://content.riscv.org/wp-content/uploads/2019/06/17.10-b_wolf.pdf and the following document: https://github.com/riscv/riscv-bitmanip/blob/master/bitmanip-0.90.pdf The aim is to provide the intrinsic functions to the user in

Hi all, Some non trivial legalization of operations which aren't supported by the backend would benefit from having the optimizer pass on them. I noticed some example trying to optimize various pieces of code over the past weeks. One offender is the cttz/ctlz intrinsic when defined on 0. On X86, BSR and NSF are undefined on 0, and only recent CPU have the LZCNT and TZCNT instructions that are properly defined for 0. The backend insert code with a branch that checks for 0 and use bsf/bsr or just use a constant. But if we are to branch anyway, and o...

On 5/18/20 8:24 PM, Craig Topper wrote: > I can tell you that your avx512 issue is that v64i8 gfni instructions also > require avx512bw to be enabled to make v64i8 a supported type. The C > intrinsics handling in the front end know this rule. But since you > generated your own intrinsics you bypassed that. Indeed that's the issue... I was stick with what Intel announces here

...It takes two integer operands of the same width, and returns an integer with twice the width of the operands. (Is there a good reason to make these the same width, as all the other operations do even when it doesn’t really make sense for the mathematical operation–like multiplication or ctpop/ctlz/cttz?) >> >>  If the CPU does not have a dedication clmul operation, it can be lowered to regular multiplication, by using holes to avoid carrys. >> >>  ==Where is clmul used?== >> >>  While somewhat specialized, the RISC-V manual documents many uses: [2] >> &gt...

...ll, > > > > Some non trivial legalization of operations which aren't supported by > the backend would benefit from having the optimizer pass on them. I noticed > some example trying to optimize various pieces of code over the past weeks. > > > > One offender is the cttz/ctlz intrinsic when defined on 0. On X86, BSR > and NSF are undefined on 0, and only recent CPU have the LZCNT and TZCNT > instructions that are properly defined for 0. The backend insert code with > a branch that checks for 0 and use bsf/bsr or just use a constant. > > > > But...

...the future, allow for more intelligent rewriting. [r224742](http://reviews.llvm.org/rL224742), [r224798](http://reviews.llvm.org/rL224798). * The masked load and store intrinsics have been documented. [r224832](http://reviews.llvm.org/rL224832). * CodeGenPrepare learned to speculate calls to llvm.cttz/ctlz (count trailing/leading zeroes) if `isCheapToSpeculateCtlz/isCheapToSpeculatCttz` in TargetLowering return true. [r224899](http://reviews.llvm.org/rL224899). ## Clang commits * The Clang internals manual has been extended with stub sections on Parse, Sema, and CodeGen. [r224894](http://revi...

...terrible quality in a lot of cases. So I’m not eager to add partial support just for out-of-tree targets. > > Marking CTLZ_ZERO_UNDEF as “LibCall” was implemented in https://reviews.llvm.org/D47917 <https://reviews.llvm.org/D47917> . Probably straightforward to extend that to cover CTTZ_ZERO_UNDEF and CTPOP. > > -Eli > > From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Joan Lluch via llvm-dev > Sent: Monday, June 10, 2019 8:31 AM > To: llvm-dev <llvm-dev at lists.llvm.org> > Subject: [EXT] [llvm-dev] Bug: Library functions for I...

...IR instructions? As noted here, it's unlikely for rotate. If it is possible, then adding folds to instcombine for this intrinsic isn't hard. Are any other passes affected? For reference, these are the current target-independent bit-manipulation intrinsics - bswap, bitreverse, ctpop, ctlz, cttz: http://llvm.org/docs/LangRef.html#bit-manipulation-intrinsics The LLVM cost for the proposed rotate intrinsic should be in the same range as those? Note that we would not just be adding code to support an intrinsic. There are already ~200 lines of DAG matching code for rotate, so we already have...

...terrible quality in a lot of cases. So I’m not eager to add partial support just for out-of-tree targets. > > Marking CTLZ_ZERO_UNDEF as “LibCall” was implemented in https://reviews.llvm.org/D47917 <https://reviews.llvm.org/D47917> . Probably straightforward to extend that to cover CTTZ_ZERO_UNDEF and CTPOP. > > -Eli > > From: llvm-dev <llvm-dev-bounces at lists.llvm.org <mailto:llvm-dev-bounces at lists.llvm.org>> On Behalf Of Joan Lluch via llvm-dev > Sent: Monday, June 10, 2019 8:31 AM > To: llvm-dev <llvm-dev at lists.llvm.org <mailto:ll...