Displaying 20 results from an estimated 500 matches similar to: "[LLVMdev] Fwd: Re: [PATCH] [TABLEGEN] Do not crash on intrinsics with names longer than 40 characters"
2014 Jul 17
2
[LLVMdev] Fwd: Re: [PATCH] [TABLEGEN] Do not crash on intrinsics with names longer than 40 characters
On 17/07/2014 20:27, Eric Christopher wrote:
> Hi Alp,
>
> On Thu, Jul 17, 2014 at 6:25 AM, Alp Toker <alp at nuanti.com> wrote:
>> Hi Manuel,
>>
>> Here's another commit authored through the web interface where no discussion
>> or reviewership information is apparent on the mailing list.
> If you look at the phab review, it's the same there.
Does
2007 Feb 05
2
[LLVMdev] automatically generating intrinsic declarations
LLVM knows what all the types of the intrinsic functions are; I thought,
why are users (including llvm-gcc...) required to duplicate all this
information in order to use them? I mean in order to call getOrInsertFunction
to get declarations for them.
So I wrote this patch, which allows all this code to be generated
automatically. Is this a good approach?
Dan
--
Dan Gohman, Cray Inc. <djg at
2016 Jun 13
2
LLVM IR intrinsics placeholder for strings [was Re: Back end with special loop instructions (using LLVM IR intrinsics)]
Hello.
I come back to this thread. But I want to ask a slightly different question.
Is there a way to have LLVM IR language intrinsics that are given at construction
time a string that is written at assembly generation time as it is? (so, basically having
placeholders of strings in LLVM that remain untouched until the end, including code
generation time.)
More exactly, I would
2007 Feb 05
0
[LLVMdev] automatically generating intrinsic declarations
On Mon, 5 Feb 2007, Dan Gohman wrote:
> LLVM knows what all the types of the intrinsic functions are; I thought,
> why are users (including llvm-gcc...) required to duplicate all this
> information in order to use them? I mean in order to call
> getOrInsertFunction to get declarations for them.
That is an excellent question! :) In the bad old days, we used to allow
intrinsics
2008 May 07
2
[LLVMdev] Creation of Intrinsics with Pointer Return Types
<table cellspacing='0' cellpadding='0' border='0' ><tr><td style='font: inherit;'>Hi,<br>I tried creating intrinsics which are to be<br>placeholders for a set of instructions (actually a section of a basic block) to be executed elsewhere(for e.g. in HW).<br>These intrinsics are to take care of the data dependencies of the set of
2008 May 07
0
[LLVMdev] Creation of Intrinsics with Pointer Return Types
Hello,
LLVM's intrinsic overloading mechanism does not currently support
overloading on pointer types. Patches to implement this would be
welcome.
Dan
On May 7, 2008, at 9:25 AM, aditya vishnubhotla wrote:
> Hi,
> I tried creating intrinsics which are to be
> placeholders for a set of instructions (actually a section of a
> basic block) to be executed elsewhere(for e.g. in
2016 May 30
1
Back end with special loop instructions
Hi Alex,
You might find it useful to look at how lib/Target/PowerPC/PPCCTRLoops.cpp works.
-Hal
----- Original Message -----
> From: "Alex Susu via llvm-dev" <llvm-dev at lists.llvm.org>
> To: "llvm-dev" <llvm-dev at lists.llvm.org>
> Sent: Monday, May 30, 2016 5:09:37 PM
> Subject: [llvm-dev] Back end with special loop instructions
>
> Hello.
2007 Feb 06
1
[LLVMdev] automatically generating intrinsic declarations
On Mon, Feb 05, 2007 at 12:28:56PM -0800, Chris Lattner wrote:
> On Mon, 5 Feb 2007, Dan Gohman wrote:
>
> > LLVM knows what all the types of the intrinsic functions are; I thought,
> > why are users (including llvm-gcc...) required to duplicate all this
> > information in order to use them? I mean in order to call
> > getOrInsertFunction to get declarations for
2016 May 30
2
Back end with special loop instructions
Hello.
I'm writing a back end for my research SIMD processor that has an assembly language
that is blocked structured, with one-level loops. An example program with my assembly
language:
REPEAT_X_TIMES(Param2)
R0 = LS[offset_A];
END_REPEAT;
The LLVM code somewhat equivalent to the above ASM program is:
vector.body:
%index = phi i64 [
2008 Feb 19
2
[LLVMdev] Problem with variable argument intrinsics
Hi,
I tried creating variable argument intrinsics which
are to be placeholders for some instructions which
should not be executed by the backend.
Kindly help me with the errors in my "migrate_begin"
intrinsic creation
//Additions made to Intrinsics.td file:
def llvm_migrate_begin : LLVMType<iAny>;
def int_migrate_begin :
2008 Feb 19
0
[LLVMdev] Problem with variable argument intrinsics
On Feb 19, 2008, at 1:11 AM, aditya vishnubhotla wrote:
> Hi,
> I tried creating variable argument intrinsics which
> are to be placeholders for some instructions which
> should not be executed by the backend.
>
> Kindly help me with the errors in my "migrate_begin"
> intrinsic creation
>
> //Additions made to Intrinsics.td file:
>
> def
2019 Oct 22
4
Complex proposal v3 + roundtable agenda
Ahead of the Wednesday’s roundtable at the developers’ conference, here is version three of
the proposal for first-class complex types in LLVM. I was not able to add Krzysztof Parzyszek’s
suggestion of a “cunzip” intrinsic returning two vectors as I could not find examples of intrinsics
that return two values at the IR level. The Hexagon intrinsics declared to return two values do
not actually
2016 Jul 26
2
Help wanted: Overloading an Intinsic
Hello All,
I have been modifying LLVM a project of mine, and have encountered issues
with overloading an intrinsic function.
I have defined two types, abit (which is mapped, in Intrinsics.td, to i128)
and qbit (accordingly mapped to i16). I would like my intrinsic function,
CNOT(x,y), to accept either an abit or a qbit for each argument, so I
overload with iAny and llvm_anyint_ty, as seemed to
2016 Jul 28
0
Help wanted: Overloading an Intinsic
Hi David,
The error shows that the clang source code uses this intrinsic as well, but in the old form. You need to modify the clang source code (where this intrinsic is used) to consider the overloaded operands.
The assert would show the trace where clang uses this intrinsic.
Hope this helps,
Anna
> On Jul 26, 2016, at 3:21 PM, David Noursi via llvm-dev <llvm-dev at lists.llvm.org>
2019 Jul 01
14
RFC: Complex in LLVM
Hey all,
I volunteered to put together a proposal regard complex in LLVM.
Consider the following to be a strawman meant to spark discussion. It's
based on real-world experience with complex but is not expected to cover
all use-cases.
Proposal to Support Complex Operations in LLVM
----------------------------------------------
Abstract
Several vendors and individuals have proposed
2008 Feb 20
1
[LLVMdev] Invalid intrinsic name error
Hi,
Thank You for the advice and we were able to solve
that problem by the following modifications to the
Instrinsics.td file.
But I now have an "Invalid Intrinsic name" error
This error occurs presumably because the created
intrinsic is named:
llvm.migrate_begin.i32
Intrinsics.gen checks for a string length of 18
(i.e. the length without the .i32).
Kindly help me through it.
2008 Feb 12
0
[LLVMdev] Inrinsic Creation Problem
Hi,
I tried creating intrinsics which are to be
placeholders for some instructions which should not be
executed by the backend.
Kindly help me with the errors in my "migrate_begin"
intrinsic creation
The following are the additions made to the
Intrinsics.td file
def llvm_migrate_begin : LLVMType<iAny>;
def int_migrate_begin :
Intrinsic<[llvm_migrate_begin,llvm_vararg_ty],
2009 Apr 15
3
[LLVMdev] Tablegen question
In IntrinsicEmitter::EmitTypeGenerate, called from
IntrinsicEmitter::EmitGenerator, here
for (unsigned j = 0; j != N; ++j) {
OS << " ArgTys.push_back(";
EmitTypeGenerate(OS, ParamTys[j], ArgNo);
OS << ");\n";
}
I'm hitting this assertion:
if (ArgType->isSubClassOf("LLVMMatchType")) {
unsigned Number =
2020 Nov 12
0
Complex proposal v3 + roundtable agenda
Hi,
There’s growing interest among our users to make better use of dedicated hardware instructions for complex math and I would like to re-start the discussion on the topic. Given that this original thread was started a while ago apologies if I missed anything already discussed earlier on the list or the round-table. The original mail is quoted below.
In particular, I’m interested in the AArch64
2015 Jan 15
2
[LLVMdev] Overloaded intrinsics: name explosion
Hi,
So, we currently have gc.result.int, gc.result.float. gc.result.ptr,
gc.relocate, and gc.statepoint. gc.statepoint's signature is fine with
a iPTRAny as the first argument. gc.result is in trouble, because none
of the signatures admit even a simple array of integers, and there's
no aAny. And certainly no vectors. So we can get a gc.result.vector to
add to this mess, and admit [1] to