similar to: [LLVMdev] patch for llc/ARM: added mechanism to move switch tables from .text -> .data; also cleanup and documentation

Evan: Sorry for the late follow up, I was out of town last week. Enclosed please find the updated patch including all your suggestions and a dejagnus test. Robert On Thu, Jun 11, 2009 at 2:27 PM, Evan Cheng <evan.cheng at apple.com> wrote: > > On Jun 8, 2009, at 2:42 PM, robert muth wrote: > > > On Sun, Jun 7, 2009 at 11:53 PM, Evan Cheng <evan.cheng at apple.com>

On Jun 8, 2009, at 2:42 PM, robert muth wrote: > On Sun, Jun 7, 2009 at 11:53 PM, Evan Cheng <evan.cheng at apple.com> > wrote: >> >> On Jun 7, 2009, at 6:59 AM, robert muth wrote: >> >>> On Sat, Jun 6, 2009 at 4:51 PM, Evan Cheng<evan.cheng at apple.com> >>> wrote: >>>> +cl::opt<std::string>

On Sun, Jun 7, 2009 at 11:53 PM, Evan Cheng <evan.cheng at apple.com> wrote: > > On Jun 7, 2009, at 6:59 AM, robert muth wrote: > >> On Sat, Jun 6, 2009 at 4:51 PM, Evan Cheng<evan.cheng at apple.com> >> wrote: >>> +cl::opt<std::string> FlagJumpTableSection("jumptable-section", >>> +                                          

Hi list: I have been trying to get my feet wet with the ARM backend. As a warmup exercise I wanted to be able to move jumptables especially large ones out of the code section. Currently the idiom for jump tables loooks like this // .set PCRELV0, (.LJTI9_0_0-(.LPCRELL0+8)) // .LPCRELL0: // add r3, pc, #PCRELV0 // ldr pc, [r3, +r0, lsl #2] // .LJTI9_0_0: //

Hi Robert, Evan asked me to review this patch, and I have some questions about it. I apologize for not following the discussion earlier and for hitting you with questions after you've already gone through several revisions. LLVM provides some default behavior for handling jump tables, with the tables emitted separately from the code that uses them. The ARM backend provides its

On Thu, Jun 25, 2009 at 6:17 PM, Bob Wilson <bob.wilson at apple.com> wrote: > Hi Robert, > Evan asked me to review this patch, and I have some questions about it. I > apologize for not following the discussion earlier and for hitting you with > questions after you've already gone through several revisions. > > LLVM provides some default behavior for handling jump

Comments below. On Apr 15, 2008, at 4:24 AM, Nicolas Geoffray wrote: > OK, here's a new patch that adds the infrastructure and the > implementation for X86, ARM and PPC of GetInstSize and > GetFunctionSize. Both functions are virtual functions defined in > TargetInstrInfo.h. > > For X86, I moved some commodity functions from X86CodeEmitter to > X86InstrInfo. >

On Sat, Jun 6, 2009 at 4:51 PM, Evan Cheng<evan.cheng at apple.com> wrote: > +cl::opt<std::string> FlagJumpTableSection("jumptable-section", > +                                           cl::init(".data.jtab")); > + I thought it would be nice to group all the jumptables together. But as long as it stays configurable, I am fine to change the default to

On Jun 7, 2009, at 6:59 AM, robert muth wrote: > On Sat, Jun 6, 2009 at 4:51 PM, Evan Cheng<evan.cheng at apple.com> > wrote: >> +cl::opt<std::string> FlagJumpTableSection("jumptable-section", >> + cl::init(".data.jtab")); >> + > > I thought it would be nice to group all the jumptables

+cl::opt<std::string> FlagJumpTableSection("jumptable-section", + cl::init(".data.jtab")); + Is this necessary? Why not just put it in the normal data section? Also "outline" jumptable seems like a strange term. Can you think of something else? Thanks, Evan Sent from my iPhone On Jun 2, 2009, at 6:26 PM, robert

On Tue, Jun 2, 2009 at 6:26 PM, robert muth<robert at muth.org> wrote: > This is my first patch submission. Hopefully, this is the proper the protocol. This is fine, although it's usually better to submit patches to llvm-commits. > Added mechanism to generate switch table in a data section > rather than having it interleaved with the code. > This is controlled by command

I have run the torture test again svn head rev 76522 (2009/07/20) there are now 2 compilation and 23 runtime failure. A tarball with reproducers is attached. Most problems are still vargs related. Robert On Fri, Jun 12, 2009 at 11:09 AM, Sandeep Patel <deeppatel1987 at gmail.com>wrote: > I don't have a target in front of me to run these tests at the moment, > but walking

On Apr 16, 2008, at 1:46 AM, Nicolas Geoffray wrote: > >> >> How about a default GetInstSize() as well? Return 1 for every >> instruction except for some special TargetInstrInfo instructions, >> e.g. >> PHI, IMPLICIT_DEF, LABEL. I don't know if it's useful or not. But >> perhaps we can default most targets to it? >> >> > > I

Just filed bugs for this and a new rather severe one involving address arithmetic. Robert On Fri, Jul 24, 2009 at 1:34 AM, Evan Cheng <evan.cheng at apple.com> wrote: > Can you file a bug? Thanks. > Evan > > On Jul 22, 2009, at 8:30 AM, robert muth wrote: > > I have run the torture test again svn head rev 76522 (2009/07/20) there are > now > 2 compilation and 23

> > How about a default GetInstSize() as well? Return 1 for every > instruction except for some special TargetInstrInfo instructions, e.g. > PHI, IMPLICIT_DEF, LABEL. I don't know if it's useful or not. But > perhaps we can default most targets to it? > > I prefer not giving a default implementation and aborting with a message that says the target did not

Hi llvm developers, I might be overlooking something, but I think the ARMConstantIsland pass uses the wrong size for the MachineInstrs representing jump tables: Currently, there is the following calculation in doInitialJumpTablePlacement (lib/Target/ARM/ARMConstantIslandPass.cpp:588): ---------------------------------------------------------------------- unsigned Size = JT[JTI].MBBs.size() *

I wrote a few scripts to run llvm/arm against the gnu c torture test suite which consists of over 900 smallish tests. There were quite a few failures with llvm/arm which I hereby want to report (see attached tarball for the actual failing testsc). Most of the failures are related to vararg/stdarg. I think I saw a bug files for this but cannot find it anymore. Is somebody on this? Finally, I

ArmConstantPoolValue is derived from MachineConstantPoolValue Is there some reason for this? Some advantage?

Can you file a bug? Thanks. Evan On Jul 22, 2009, at 8:30 AM, robert muth wrote: > I have run the torture test again svn head rev 76522 (2009/07/20) > there are now > 2 compilation and 23 runtime failure. A tarball with reproducers is > attached. > Most problems are still vargs related. > > Robert > > On Fri, Jun 12, 2009 at 11:09 AM, Sandeep Patel

On Tue, Jul 14, 2009 at 6:48 PM, Bob Wilson <bob.wilson at apple.com> wrote: > > On Jul 2, 2009, at 10:48 AM, robert muth wrote: > > I spend over a day trying to follow your suggestion. In the end I was not > successful. Here is what Iearned: > > After setting > > ARMJITInfo::hasCustomJumpTables -> true > setOperationAction for ISD::BR_JT -> Expand >