Displaying 20 results from an estimated 10000 matches similar to: "[LLVMdev] New Configure Option for LLVM Builds"
2011 Jun 20
0
[LLVMdev] New Configure Option for LLVM Builds
On 6/20/11 10:39 AM, Justin Holewinski wrote:
> For the PTX back-end, I would like to introduce a configure-time
> option to determine the number of architectural registers available to
> LLVM register allocation during code generation. The motivation for
> this is PTX is a virtual instruction set and the number of registers
> is configurable in the output file. Thus, the
2011 Jun 20
2
[LLVMdev] New Configure Option for LLVM Builds
On Jun 20, 2011, at 11:47 AM, John Criswell wrote:
> On 6/20/11 10:39 AM, Justin Holewinski wrote:
>>
>> For the PTX back-end, I would like to introduce a configure-time option to determine the number of architectural registers available to LLVM register allocation during code generation. The motivation for this is PTX is a virtual instruction set and the number of registers is
2011 May 13
1
[LLVMdev] [ptx] Propose a register class naming convention change
2011/5/13 Dan Bailey <drb at dneg.com>
> Justin Holewinski wrote:
>
> On Fri, May 13, 2011 at 5:11 AM, Dan Bailey <drb at dneg.com> wrote:
>
>> That's fine with me. Unless there's a particular reason for it I would
>> suggest perhaps changing the immediate syntax as well to swap it round, so
>> it would be Immi32, Immi64, Immf32, etc. It
2013 Feb 11
2
[LLVMdev] Emulating an infinite register file in the backend
Hi Justin and all,
you've mentioned that you used an easy "trick" for defining an
infinite register file in the backend.
Does this involve defining a single dummy register, and then adding
this dummy reg to each register class? Is anything more needed? I
refer to the RegisterInfo.td file, as e.g:
llvm-3.0.src/lib/Target/PTX/PTXRegisterInfo.td
I'm (just starting)
2011 May 13
2
[LLVMdev] [ptx] Propose a register class naming convention change
On Fri, May 13, 2011 at 5:11 AM, Dan Bailey <drb at dneg.com> wrote:
> That's fine with me. Unless there's a particular reason for it I would
> suggest perhaps changing the immediate syntax as well to swap it round, so
> it would be Immi32, Immi64, Immf32, etc. It doesn't bother me that much the
> way it currently is, but when there are lots of operations taking a
2011 May 13
0
[LLVMdev] [ptx] Propose a register class naming convention change
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Justin Holewinski wrote:
<blockquote
cite="mid:BANLkTi=Y9EFmWRu-9dQxydq8zTyF7tEbJw@mail.gmail.com"
2013 Feb 12
0
[LLVMdev] Emulating an infinite register file in the backend
On Mon, Feb 11, 2013 at 6:32 PM, <nkavv at physics.auth.gr> wrote:
> Hi Justin and all,
>
> you've mentioned that you used an easy "trick" for defining an infinite
> register file in the backend.
>
The original PTX back-end just didn't perform register allocation. All
registers emitted in the assembly were virtual registers, mapped to a
consecutive range.
2012 May 01
2
[LLVMdev] [PATCH][RFC] Add llvm.codegen Intrinsic To Support Embedded LLVM IR Code Generation
Justin Holewinski <justin.holewinski at gmail.com> writes:
> I don't think the code base changes are all that bad. We have a number
> of them to support generating code one function at a time rather than a
> whole module together. They've been sitting around waiting for us to
> send them upstream. It would be an easy matter to simply annotate each
>
2011 Dec 04
2
[LLVMdev] PTX builtin functions.
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 included by PTXIntrinsicInfo.cpp.
This is a quite big modification, do you agree with this ?
Or do you have a better solution.
2011 Nov 21
2
[LLVMdev] PTX builtin functions.
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
2011 Nov 21
1
[LLVMdev] PTX builtin functions.
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
2011 Dec 08
3
[LLVMdev] PTX builtin functions.
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.
Micah
From: Justin Holewinski [mailto:justin.holewinski at gmail.com]
Sent: Monday, December 05, 2011 6:13 AM
To: Alberto Magni
Cc: Villmow, Micah; LLVM Developers Mailing List
2011 Dec 08
0
[LLVMdev] PTX builtin functions.
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?
2011 Dec 05
0
[LLVMdev] PTX builtin functions.
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
2011 Nov 23
2
[LLVMdev] PTX builtin functions.
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;
>
2011 Nov 22
2
[LLVMdev] PTX builtin functions.
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
2011 Nov 23
0
[LLVMdev] PTX builtin functions.
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
2011 Nov 21
0
[LLVMdev] PTX builtin functions.
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
2011 Nov 22
0
[LLVMdev] PTX builtin functions.
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
>> >
2011 Jun 20
0
[LLVMdev] New Configure Option for LLVM Builds
On Jun 20, 2011, at 8:53 AM, Justin Holewinski wrote:
> However, as far as I know, LLVM requires static register data that is generated from tablegen files.
TableGen is not required, you can provide your own TargetRegisterInfo sub-class. That's a lot of work, though, and I wouldn't recommend it.
/jakob