similar to: Let's stop using target specific intrinsics in generic code

Hi LLVM developers, After Remove int_x86_sse2_psll_dq_bs and int_x86_sse2_psrl_dq_bs intrinsics. The builtins aren't used by clang. https://reviews.llvm.org/rL229069 there was no Intrinsic::x86_sse2_psrl_dq any more, then how to migrate: Function *F = Intrinsic::getDeclaration(TheModule, Intrinsic::x86_sse2_psrl_dq); Result = Builder.CreateCall(F,

On Dec 23, 2014, at 10:28 AM, Chris Bieneman <beanz at apple.com> wrote: >>> It should be straight-forward to have something like LLVMInitializeX86Target/RegisterTargetMachine install the intrinsics into a registry. >> >> I tried doing that a few years ago. It’s not nearly as easy as it sounds because we’ve got hardcoded references to various target intrinsics scattered

Hi! Attached patches split init.trampoline into adjust.trampoline and init.trampoline, like in gcc. As mentioned in the previous mail, I've not made a documentation patch, since I'm not sure about what the documented semantics of llvm.adjust.trampoline should be. Thanks! -- Sanjoy Das http://playingwithpointers.com -------------- next part -------------- A non-text attachment was

The ARM Neon load, store and shuffle operations that I've been implementing recently with LLVM intrinsics do not care about the distinction between vectors with i32 and f32 elements -- only the size matters. But, because we have only MVT::fAny and MVT::iAny types, I've been having to define separate intrinsics for the operations with floating-point vector elements. It

Hi! Attached set of patches splits llvm.init.trampoline into an "init" phase and an "adjust" phase, as discussed on the "Go on dragonegg" thread. Thanks! -- Sanjoy Das http://playingwithpointers.com -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Split-intrinsics-and-DAG-nodes.patch Type: text/x-diff Size: 8808 bytes Desc:

On Aug 8, 2009, at 11:47 PM, Bob Wilson wrote: > The ARM Neon load, store and shuffle operations that I've been > implementing recently with LLVM intrinsics do not care about the > distinction between vectors with i32 and f32 elements -- only the size > matters. But, because we have only MVT::fAny and MVT::iAny types, > I've been having to define separate intrinsics for

After worked around the problem in SimplifyCFG.cpp (calling isCast() instead of comparing opcode), I hit another gcc crash for FunctionImport.cpp line 480, which I have no idea what's wrong with the code. "Luckily", I found gcc4.8.2 and gave it a try, both crashes are gone. *New problem though:* /llvm-clang-trunk/src/tools/clang/lib/CodeGen/CGBuiltin.cpp: In member function

Hi all, Please consider committing the attached patch. I believe the SSE2 packsswb, packssdw and packuswb intrinsics have an incorrect return type. Thanks, Nicolas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090609/85ed0b5e/attachment.html> -------------- next part -------------- A

> -----Original Message----- > From: Chris Lattner <clattner at nondot.org> > Sent: Wednesday, February 5, 2020 4:02 PM > To: Eli Friedman <efriedma at quicinc.com> > Cc: llvm-dev <llvm-dev at lists.llvm.org> > Subject: [EXT] Re: [llvm-dev] [RFC] Extending shufflevector for vscale vectors > (SVE etc.) > > On Jan 29, 2020, at 4:48 PM, Eli Friedman via

On Tue, Jun 9, 2009 at 2:58 PM, Nicolas Capens<nicolas at capens.net> wrote: > Please consider committing the attached patch. I believe the SSE2 packsswb, > packssdw and packuswb intrinsics have an incorrect return type. If we really wanted to do this, an AutoUpgrade patch would be necessary for backwards-compatibility. I'm not sure it's worth bothering. -Eli

ok, I now have a problem in the code generator. Let's say I want to set a breakpoint somewhere in clang/lib/CodeGen/CGExprScalar.cpp What do I have to do in order to trigger breakpoints, see backtraces and so on? -- Roland ----- Original Message ----- > From: "Eric Christopher" <echristo at apple.com> > To: "Roland Leißa" <leissa at cs.uni-saarland.de>

Hi, For a small case, that calls NULL pointer function. LLVM explicitly converts It to a store because it thinks it is not reachable like calling undefvalue. In InstCombineCalls.cpp:930 I think it is not a right approach because calling null pointer function Will segfault the program. Converting to a store will make program pass Silently. This changes the behavior of a program.

I ran into an LLVM/Clang crash when attempting to do the following: 1. Build Clang from the release/9.x branch source. 2. Use the Clang from (1) to build clangd on the release/9.x branch, with LLVM_ENABLE_MODULES=On. I wrote a script to reproduce the crash: https://gist.github.com/modocache/ac366ca9673b93bb21e75d3e72162608 At the above URL, you'll find a script `repro.sh` that reproduces

On 2 October 2013 13:36, Hal Finkel <hfinkel at anl.gov> wrote: > You can certainly do this in terms of an LLVM transformation, but I think > that creating some kind of header file would be, at least, where I'd start > prototyping this. > Yes, this is a good approach to understanding the problem. But I wouldn't use this as a final solution, as it scales quadratically

Hi Sanjoy, the first and last patches look good (except that you didn't add any tests for the auto-upgrade functionality). Comments on the other two below. > Attached patches split init.trampoline into adjust.trampoline and > init.trampoline, like in gcc. > > As mentioned in the previous mail, I've not made a documentation > patch, since I'm not sure about what the

> Neither worked. =( Hmm. Something seems to have gone horribly wrong then. I've just reproduced Peter's suggestion on the autoconf build and it worked fine. Perhaps try a clean build out of tree: CMake: mkdir my_special_build_dir cd my_special_build_dir cmake $PATH_TO_LLVM_SOURCE make llc Autotools: mkdir my_special_build_dir cd my_special_build_dir $PATH_TO_LLVM_SOURCE/configure

Hi Eli, What exactly do mean by an AutoUpgrade patch? I don't see how this could cause any issues with backward compatibility. People currently using these intrinsics need a bitcast of the result to avoid an assert, and with the patch applied the bitcast is no longer necessary. Cheers, Nicolas -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at

----- Original Message ----- > On 2 October 2013 12:17, Renato Golin < renato.golin at linaro.org > > wrote: > > > > > On 2 October 2013 10:12, Steven Newbury < steve at snewbury.org.uk > > wrote: > > > > > > How does this make any sense? > > > I have to agree with you that this doesn't make much sense, but there > is

On Aug 9, 2009, at 8:37 AM, Chris Lattner wrote: > I really do think that bitcast is the right way to go here. I ran > into a couple of similar problems when bringing up the altivec port. > For example, at one time we'd get "all zero vectors" of different > MVTs, which would not be CSEd. > > The fix for this was to be really disciplined about what types to make

On Apr 20, 2012, at 6:35 PM, Roland Leißa <leissa at cs.uni-saarland.de> wrote: > ok, I now have a problem in the code generator. > Let's say I want to set a breakpoint somewhere in > clang/lib/CodeGen/CGExprScalar.cpp > > What do I have to do in order to trigger breakpoints, see backtraces and so on? You set a breakpoint and ask to see a backtrace? -eric