similar to: [LLVMdev] Adding Intrinsics for custom processor (frotend, problem)

As mentioned in an earlier mail, I am working on an LLVM backend for a custom processor based on MIPS. My problem is how to extend LLVM to support some esoteric/non-standard feature of the underlying hardware. I saw in the "Extending LLVM" document, that the easiest / most common way to do this was using an intrinsic function, and examples of the technique abound (all SSE for

Personally I would just modify the frontend - it's not that hard once you know where to look . In this case all you need to do is add the declaration of your builtin to the TARGET_INIT_BUILTINS target hook (see the gcc internals manual) defined in the gcc/config directory corresponding to your target. If the name the the declaration matches the name used with GCCBuiltin in the intrinsics

Chris Lattner wrote: > As others have mentioned, hacking the front-end isn't that hard. In > any case though, please be aware that a precompiled binary for a non- > MIPS target won't produce correct code if you are (for example) using > an x86 front-end and forcing llc to generate mips code with llc - > march=mips. The front-end does type layout and knows very ABI

If I do T.getArch() == xxx TLI.setUnavailable(LibFunc::copysign) then this works at generating a call instead of not being able to select the ISD::FCOPYSIGN, but I don't know why I don't need to do this for other LibFunc functions (such as floor, etc... these generate call just fine)? Thanks, Ryan On Tue, Jun 14, 2016 at 11:58 AM, Ryan Taylor <ryta1203 at gmail.com> wrote:

On Tue, Jan 24, 2012 at 1:36 PM, Kostya Serebryany <kcc at google.com> wrote: > ASAN *can* be modified this way (it will actually make instrumentation > ~10% cheaper). > But this mode will miss some bugs that the current mode finds. > I've seen at least a couple of such *real* bugs. > > And these bugs are not only about exploitability, but also about > correctness.

On Wed, Nov 16, 2011 at 8:05 AM, Alberto Magni <alberto.magni86 at gmail.com>wrote: > Dear Justin, > > I am trying to add the support for some OpenCL builtin functions to > the PTX backend. > The attached file represent the first stub of a patch for the fmax > builtin function. > First off, thanks for helping to improve the PTX back-end! There are really two main

Hi Chandler, > On Tue, Jan 24, 2012 at 1:36 PM, Kostya Serebryany <kcc at google.com > <mailto:kcc at google.com>> wrote: > > ASAN *can* be modified this way (it will actually make instrumentation ~10% > cheaper). > But this mode will miss some bugs that the current mode finds. > I've seen at least a couple of such *real* bugs. > >

On Mon, Nov 21, 2011 at 3:36 PM, Justin Holewinski <justin.holewinski at gmail.com> wrote: > On Mon, Nov 21, 2011 at 7:01 AM, Alberto Magni <alberto.magni86 at gmail.com> > wrote: >> >> Hi Justin, >> >> attached you find the patch for the integer max instruction. >> The multiclass PTX_INTRINSIC_INT3 in file PTXIntrinsicInstrInfo.td >> is almost

On Mon, Nov 21, 2011 at 7:01 AM, Alberto Magni <alberto.magni86 at gmail.com>wrote: > Hi Justin, > > attached you find the patch for the integer max instruction. > The multiclass PTX_INTRINSIC_INT3 in file PTXIntrinsicInstrInfo.td > is almost an exact copy of PTX_INT3 in PTXInstrInfo.td, maybe > a modification of this class can be defined in a separate file. > I'm

Folks, I just had a discussion about __builtin_stack_pointer in the GCC list, and there were a number of arguments against it, and it got me thinking I didn't have strong arguments against GNU's named register extension. Does anyone remember the arguments for not implementing that extension? My view is that making it an intrinsic (say @llvm.register(name)) would have the exact same

On Mon, Nov 21, 2011 at 5:31 PM, Justin Holewinski <justin.holewinski at gmail.com> wrote: > On Mon, Nov 21, 2011 at 11:45 AM, Alberto Magni <alberto.magni86 at gmail.com> > wrote: >> >> On Mon, Nov 21, 2011 at 3:36 PM, Justin Holewinski >> <justin.holewinski at gmail.com> wrote: >> > On Mon, Nov 21, 2011 at 7:01 AM, Alberto Magni >> >

On Mon, Nov 21, 2011 at 11:45 AM, Alberto Magni <alberto.magni86 at gmail.com>wrote: > On Mon, Nov 21, 2011 at 3:36 PM, Justin Holewinski > <justin.holewinski at gmail.com> wrote: > > On Mon, Nov 21, 2011 at 7:01 AM, Alberto Magni < > alberto.magni86 at gmail.com> > > wrote: > >> > >> Hi Justin, > >> > >> attached you find

On Tue, Nov 22, 2011 at 5:01 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > Alberto, >  The AMDIL backend solves your problem with intrinsic overloading this way: > def int_AMDIL_mad     : GCCBuiltin<"__amdil_mad">, TernaryIntFloat; > > Where TernaryIntFloat is defined as: > class TernaryIntFloat : >          Intrinsic<[llvm_anyfloat_ty],

On Nov 23, 2011 8:33 AM, "Justin Holewinski" <justin.holewinski at gmail.com> wrote: > > > On Nov 23, 2011 6:57 AM, "Alberto Magni" <alberto.magni86 at gmail.com> wrote: > > > > On Tue, Nov 22, 2011 at 5:01 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > > > Alberto, > > > The AMDIL backend solves your problem

Alberto, The AMDIL backend solves your problem with intrinsic overloading this way: def int_AMDIL_mad : GCCBuiltin<"__amdil_mad">, TernaryIntFloat; Where TernaryIntFloat is defined as: class TernaryIntFloat : Intrinsic<[llvm_anyfloat_ty], [LLVMMatchType<0>, LLVMMatchType<0>, LLVMMatchType<0>], []>; This allows us to write a

On Nov 23, 2011 6:57 AM, "Alberto Magni" <alberto.magni86 at gmail.com> wrote: > > On Tue, Nov 22, 2011 at 5:01 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > > Alberto, > > The AMDIL backend solves your problem with intrinsic overloading this way: > > def int_AMDIL_mad : GCCBuiltin<"__amdil_mad">, TernaryIntFloat; >

On Tue, Jun 7, 2016 at 1:57 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > Tim, > > Currently, I have to do multiple things: > > 1) create some setLibcallNames in XXXISelLowering.cpp to generate correct > naming for RTLIBS. > 2) lower ISD down to an RTLIB for some calls (and then do solution 1 on > those to get correct names) These solve a related but different -

On Sun, Dec 4, 2011 at 1:10 PM, Alberto Magni <alberto.magni86 at gmail.com>wrote: > Hi Justin, > > sorry for the delay, I have been busy. > > Micah's proposal requires to move the definitions of the intrinsics > from include/llvm/IntrinsicsPTX.td to lib/Target/PTX/PTXIntrinsics.td > thus allowing the generation of the file PTXGenIntrinsics.inc which > will be

On 2/18/2013 8:08 PM, Chris Lattner wrote: > > That code is presumably compiled by someone. If whoever compiles it specifies -fno-builtin, the attribute would be added to it. It doesn't affect its clients. I thought that no-builtin attached to foo means that foo should not be considered a builtin function. For example, if someone wrote their own printf, they may want to mark it as

On Thu, Dec 8, 2011 at 11:36 AM, Villmow, Micah <Micah.Villmow at amd.com>wrote: > It is my understanding that all you need to do is specify let isTarget = > 1 in your .td file and it will generate target specific intrinsics. This > should allow you to keep the IntrinsicsPTX.td file in the same location. > So we keep the intrinsics defined in include/llvm/IntrinsicsPTX.td?