similar to: [LLVMdev] [PATCH] increase the max number of physical registers

Hello, Can someone please commit this patch? Thanks. On 11/21/2009 11:15 PM, Pekka Jääskeläinen wrote: > Hello, > > Attached is a trivial patch to increase the max number of physical > registers in LLVM from 1024 to 16384. > > In our TCE toolset we allow the designer to choose the number of > registers in the designed TTA processors freely, and recently > while

On Nov 21, 2009, at 1:15 PM, Pekka Jääskeläinen wrote: > Hello, > > Attached is a trivial patch to increase the max number of physical > registers in LLVM from 1024 to 16384. > > In our TCE toolset we allow the designer to choose the number of registers in the designed TTA processors freely, and recently > while experimenting with using TTA for a GPU design we have >

Here's the actual patch, sorry ;) On 12/07/2009 09:02 PM, Pekka Jääskeläinen wrote: > Hello, > > Can someone please commit this patch? > > Thanks. > > On 11/21/2009 11:15 PM, Pekka Jääskeläinen wrote: >> Hello, >> >> Attached is a trivial patch to increase the max number of physical >> registers in LLVM from 1024 to 16384. >> >> In

Hello LLVM people, Our customizable TTA target [1] is capable of having plenty of registers and register file ports to improve instruction level parallelism and reduce spills. It's totally up to the designer of the particular TTA processor how much the processor has registers and register file resources along with other TTA components. We have ported LLVM 2.1 to produce an intermediate TTA

Hi all, I think this master's thesis from our group could be of interest. It describes the "bridge" between the LLVM codegen and our custom TTA codegen in TCE: a runtime retargetable architecture description file driven LLVM compiler backend. The thesis might be useful also for people implementing backends for LLVM in general. http://tce.cs.tut.fi/doc/Compiler.pdf If you have any

Hello, Pekka >Attached is a trivial patch to increase the max number of physical >registers in LLVM from 1024 to 16384. Just random thought - could this be a configure-time option? -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

On Nov 5, 2007, at 2:55 AM, Pekka Jääskeläinen wrote: > Hello LLVM people, > > Our customizable TTA target [1] is capable of having plenty of > registers > and register file ports to improve instruction level parallelism and > reduce spills. It's totally up to the designer of the particular TTA > processor how much the processor has registers and register file >

Hi, On 06/18/2011 06:26 AM, Benjamin Müller wrote: > i created a Function Pass to retrieve the Control/Data Flow Graph from > a simple program, > now i would like to statically schedule the Instructions. Is this > possible by starting to modify the SelectionDAG Files ? > Or can i even build a "standalone" custom scheduler? > Thank you very much for any tipps. You

Hi there, i created a Function Pass to retrieve the Control/Data Flow Graph from a simple program, now i would like to statically schedule the Instructions. Is this possible by starting to modify the SelectionDAG Files ? Or can i even build a "standalone" custom scheduler? Thank you very much for any tipps. Ben

Hello, This patch was reverted and the revert was forgotten to be undone after the performance regression it introduced was fixed. Can someone please revert it back (i.e. increase the max physreg size to 16K or even better to 32K) to enable us to experiment with large register number machines again? :) It was this trivial patch: Index: include/llvm/Target/TargetRegisterInfo.h

TTA-Based Codesign Environment (TCE) is a toolset for designing application-specific processors (ASP) based on the Transport Triggered Architecture (TTA). TTA is a minimalistic processor architecture template that allows high level of control for the designer to choose the boundary between the hardware and the software. The toolset provides a complete codesign flow from C programs down to

hi guys I need to get llvm to support vliw architecture. Can you please point me in the right direction. we have managed to get it to compile into simple assemble and now need it to be able to schedule the instructions in parrallel. any help would be appreciated Regards Junior

Hi, Chris Lattner wrote: > This is fine to me in principle, but please make sure this doesn't > impact compile time or memory usage of llc somehow. OK. Any recommended way to do this? Is there some nice way to benchmark speed + memory consumption of llc in LLVM testing infra at the moment or should I just use 'top' to the inspect memory consumption and 'time' for speed

Hi, I wrote an LLVM blog post about our use of LLVM in the TCE project and a bit of a background for the TCE project in general. I hope some of you will find it interesting :) http://blog.llvm.org/2010/06/tce-project-co-design-of-application.html -- Pekka

On Jun 9, 2011, at 8:09 PM, David A. Greene wrote: > Note that things like instruction frequencies are highly ISA- > dependent. If possible, it is best to evaluate your ideas on more > than one target, just to see what the effects are. What other sorts > of things do you want to study? > > If, long-term, you are planning to do serious studies of performance >

hi Jääskeläinen, i am very interesting in the way you write the RegisterInfo.td for the machine with such a lot registers, or it is generated by some others program? best regards ether 2010/7/6 Pekka Jääskeläinen <pekka.jaaskelainen at tut.fi>: > Hello, > > This patch was reverted and the revert was forgotten to be undone > after the performance regression it introduced was

2010/6/29 Pekka Jääskeläinen <pekka.jaaskelainen at tut.fi>: > Hi, > > I wrote an LLVM blog post about our use of LLVM in the TCE project and a bit > of a background for the TCE project in general. I hope some of you will find > it interesting :) > > http://blog.llvm.org/2010/06/tce-project-co-design-of-application.html I'll ask here (rather than the TCE list)

Hello, I haven't yet received any input what this patch breaks (some LLVM-external project?) and the branch creation date is tomorrow. Can someone please tell what we can do to make this patch merged in for 2.8? Thanks! On 07/06/2010 01:26 PM, Pekka Jääskeläinen wrote: > Hello, > > This patch was reverted and the revert was forgotten to be undone > after the performance

Hi, On 08/09/2012 10:03 PM, Sergei Larin wrote: > I also tried to mess with PostRA scheduler to achieve similar goals, only > to find out that all the additional dependencies after RA make it virtually > impossible to produce high quality schedule, and obviously it is too late at > that point to address reg pressure via scheduling techniques, so I have put > that project on the

On Dec 8, 2009, at 3:31 PM, Jakob Stoklund Olesen wrote: > > On Dec 8, 2009, at 11:33 AM, Evan Cheng wrote: > >> This caused a massive slow down to post-ra scheduler (llc -O3 on x86, -O2 on ARM). I'm going to revert it for now until it has been addressed. > > Probably caused by this member: > > /// KillIndices - The index of the most recent kill (proceding