Displaying 20 results from an estimated 60000 matches similar to: "[LLVMdev] TargetRegisterInfo and "infinite" register files"
2011 May 16
0
[LLVMdev] TargetRegisterInfo and "infinite" register files
Justin,
We have the same issue with the AMDIL code generator. We tried #1, but there are passes after register allocator that don't like virtual registers. #3 could be done by having the two spill functions [load|store]Reg[From|To]StackSlot keep track of the FrameIndex to register mapping internally, but again, more of a hack than a proper solution.
My solution was to just create a very large
2011 May 16
0
[LLVMdev] TargetRegisterInfo and "infinite" register files
On May 16, 2011, at 6:52 AM, Justin Holewinski wrote:
> Currently, the TableGen register info files for all of the back-ends define concrete registers and divide them into logical register classes. I would like to get some input from the LLVM experts around here on how best to map this model to an architecture that does *not* have a concrete, pre-defined register file. The architecture is
2011 May 17
3
[LLVMdev] TargetRegisterInfo and "infinite" register files
On May 17, 2011, at 11:32 AM, Andrew Clinton wrote:
> On 05/17/2011 12:54 PM, Jakob Stoklund Olesen wrote:
>> What you can do instead is:
>>
>> 1) Just use virtual registers and skip register allocation, or
>>
>> 2) Allocate to a small register file, implement memory operand folding, and pretend that spill slots are registers.
>>
>> /jakob
>>
2011 May 17
0
[LLVMdev] TargetRegisterInfo and "infinite" register files
On Tue, May 17, 2011 at 2:52 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote:
>
> On May 17, 2011, at 11:32 AM, Andrew Clinton wrote:
>
> > On 05/17/2011 12:54 PM, Jakob Stoklund Olesen wrote:
> >> What you can do instead is:
> >>
> >> 1) Just use virtual registers and skip register allocation, or
> >>
> >> 2) Allocate to a
2011 May 17
1
[LLVMdev] TargetRegisterInfo and "infinite" register files
On May 17, 2011, at 2:10 PM, Justin Holewinski wrote:
> I plan on eventually implementing both and seeing which works best for different types of input.
>
> If virtual registers are used, how do you disable final register allocation in the back-end?
If post-RA passes have trouble with virtual registers, you probably need to implement your own addCommonCodeGenPasses() method.
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
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
2011 May 17
0
[LLVMdev] TargetRegisterInfo and "infinite" register files
I have faced this same problem in my backend, and I'm working around it
by providing a large physical register set. There are two problems with
this:
1. There's a chance that the register allocator will run out of
registers to assign, in which case the allocation will fail - making it
necessary to retry with a larger register set
2. The code generator consumes storage proportional to
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"
2011 May 13
0
[LLVMdev] [ptx] Propose a register class naming convention change
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 register and an immediate, representing them in the same way
might be a little more
2011 May 13
3
[LLVMdev] [ptx] Propose a register class naming convention change
Hi,
Current register class naming has a confusing prefix letter 'R' (it is
my bad), such as the first 'R' of RRegu32 (for unsigned 32-bit
registers).
I propose a 'Reg' + type name naming convention for register classes; such as:
Regu16, Regu32, Regf32, Regf64
With one exception for predicate registers (capitalized first letter of 'pred'):
RegPred
Since
2012 Jun 12
2
[LLVMdev] [NVPTX] For linkonce_odr NVPTX generates .weak, but even newest PTXAS can't handle it
Dear LLVM NVPTX maintainers,
Just to have the issue recorded, I don't know how important it is:
clang generates linkonce_odr out of __inline__, and NVPTX generates .weak
out of linkonce_odr (how it happens - a big question, btw, because I can't
find anything related in NVPTX asm printer - does it chain to some other
printer?), and finally ptxas (both 4.2 and 5) fails to compile it to
2012 Jun 13
0
[LLVMdev] [NVPTX] For linkonce_odr NVPTX generates .weak, but even newest PTXAS can't handle it
On Tue, Jun 12, 2012 at 6:11 PM, Dmitry N. Mikushin <maemarcus at gmail.com>wrote:
> Dear LLVM NVPTX maintainers,
>
> Just to have the issue recorded, I don't know how important it is:
>
> clang generates linkonce_odr out of __inline__, and NVPTX generates .weak
> out of linkonce_odr (how it happens - a big question, btw, because I can't
> find anything related
2014 Apr 21
2
[LLVMdev] [NVPTX] Eliminate common sub-expressions in a group of similar GEPs
Hi Hal,
Thanks for your comments! I'm inlining my responses below.
Jingyue
On Sat, Apr 19, 2014 at 6:38 AM, Hal Finkel <hfinkel at anl.gov> wrote:
> Jingyue,
>
> I can't speak for the NVPTX backend, but I think this looks useful as an
> (optional) target-independent pass. A few thoughts:
>
> - Running GVN tends to be pretty expensive; have you tried EarlyCSE
2012 Jul 18
2
[LLVMdev] [NVPTX] PTXAS - Unimplemented feature: labels as initial values
Dear NVPTX community,
PTXAS fails to compile the ptx code generated by NVPTX. Is it an issue of
backend or an issue of PTXAS or a known reasonable restriction?
Thanks,
- Dima.
> cat test.ll
; ModuleID = '__kernelgen_main_module'
target datalayout = "e-p:64:64-i64:64:64-f64:64:64-n1:8:16:32:64"
target triple = "ptx64-unknown-unknown"
%struct.__st_parameter_dt.0.4
2011 May 16
0
[LLVMdev] LLVMdev Digest, Vol 83, Issue 25
Justin,
here's another way to look at it....
you are asking for a "half" [*] of a register allocator, in that a
traditional graph coloring allocator
is divided into a coloring algorithm followed by (sometimes
integrated with) a spilling
algorithm, but what you want is just the coloring part without the
spilling part.
the coloring algorithm is so trivial that you
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
2012 Jul 18
0
[LLVMdev] [NVPTX] PTXAS - Unimplemented feature: labels as initial values
In ptx, variables need to be defined before referenced. NVPTX emits the global variables in the order as in the LLVM IR and does not sort them. It is a bug in the NVPTX backend.
Thanks.
Yuan
From: Dmitry N. Mikushin [mailto:maemarcus at gmail.com]
Sent: Wednesday, July 18, 2012 7:44 AM
To: LLVM-Dev
Cc: Justin Holewinski; Yuan Lin
Subject: [NVPTX] PTXAS - Unimplemented feature: labels as
2013 Aug 08
2
[LLVMdev] Can I add GlobalVariable in MachineFunctionPass ?
Yes, total number of PTX registers that will be emitted is exactly what I
need. It's hard to figure out this in LLVM IR level.
2013/8/7 Justin Holewinski <justin.holewinski at gmail.com>
> Is there any way you could approximate the register/instruction usage and
> perform live-range analysis in a higher-level LLVM IR pass? I'm not sure
> how useful NVPTXRegisterInfo
2011 May 17
2
[LLVMdev] TargetRegisterInfo and "infinite" register files
On May 17, 2011, at 9:18 AM, Andrew Clinton wrote:
> I have faced this same problem in my backend, and I'm working around it by providing a large physical register set. There are two problems with this:
>
> 1. There's a chance that the register allocator will run out of registers to assign, in which case the allocation will fail - making it necessary to retry with a larger