similar to: [LLVMdev] LLVMdev Digest, Vol 75, Issue 32

Hi Jim! On Tue, Sep 14, 2010 at 11:08 AM, Jim Grosbach <grosbach at apple.com> wrote: > Hi Jason, > > I've just started actively working on this. Coordinating to get things moving even faster sounds great! Can you elaborate a bit on your ultimate goals and use cases are? That might help us better determine a natural breakdown and separation of tasks. Evan and Chris may have

I see strangeness on Thumb TST (tTST) predicate 'isCompare' It is true for regular ARM, false for Thumb: (gdb) p MI->dump() TSTri %reg16397, 3, pred:14, pred:%reg0, %CPSR<imp-def>; GPR:% reg16397 $24 = void (gdb) p MI->getDesc().isCompare() $25 = true (gdb) p MI->dump() tTST %reg16396, %reg16397, pred:14, pred:%reg0, %CPSR<imp-def>; tGPR:%reg16396,16397

On Sep 14, 2010, at 12:09 PM, Gabor Greif wrote: > I see strangeness on Thumb TST (tTST) predicate 'isCompare' > > It is true for regular ARM, false for Thumb: > > (gdb) p MI->dump() > TSTri %reg16397, 3, pred:14, pred:%reg0, %CPSR<imp-def>; GPR:% > reg16397 > $24 = void > (gdb) p MI->getDesc().isCompare() > $25 = true > > > (gdb)

Hi Jason, I've just started actively working on this. Coordinating to get things moving even faster sounds great! Can you elaborate a bit on your ultimate goals and use cases are? That might help us better determine a natural breakdown and separation of tasks. Evan and Chris may have suggestions there, too, as I know they're both very interested in getting this stuff fleshed out and

Hi everyone, Rafael has graciously given me some pointers for helping out on the ARM/MC .s emission infrastructure, and I am volunteering to do so. It looks like as of yesterday, the MC obj emitter for ARM is also incomplete (there does not seem to be a ARMMCCodeEmitter.cpp, for example) So if anyone already has started looking into this, I'd like to pool info so as to not step on toes. Any

On Sep 14, 2010, at 11:26 AM, Jason Kim wrote: > Hi Jim! > > On Tue, Sep 14, 2010 at 11:08 AM, Jim Grosbach <grosbach at apple.com> wrote: >> Hi Jason, >> >> I've just started actively working on this. Coordinating to get things moving even faster sounds great! Can you elaborate a bit on your ultimate goals and use cases are? That might help us better

---------- Forwarded message ---------- From: Jason Kim <jasonwkim at google.com> Date: Fri, Oct 22, 2010 at 12:59 PM Subject: Re: [llvm-commits] Fwd: Proof of concept patch for unifying the .s/ELF emission of .ARM.attributes To: Rafael Espíndola <rafael.espindola at gmail.com> On Fri, Oct 22, 2010 at 12:51 PM, Jason Kim <jasonwkim at google.com> wrote: > On Thu, Oct 21,

Is the rationale that llvm has matured/advanced to the point where integration tests are the only ones to make sense from a test density perspective? On Thu, Sep 16, 2010 at 5:05 PM, Jason Kim <jasonwkim at google.com> wrote: > Hi everyone, > > I am trying to get up to speed on the MC object file emission for ARM, > the first cut being for ELF, and the testing required for that.

Hi everyone, I am sending this email after some time consuming exploration into how LLVM executes its tests. I first noticed this issue when Rafael noticed that my patch I sent in to llvm-commits broke some tests. I was initially very skeptical, as I had run the make check test from the build directory before sending in the patch, but as it turns out, several issues came together in a perfect

+llvmdev -llvmcommits On Fri, Nov 12, 2010 at 8:03 AM, Jim Grosbach <grosbach at apple.com> wrote: > Sorta. getBinaryCodeForInst() is auto-generated by tablegen, so shouldn't be modified directly. The target can register hooks for instruction operands for any special encoding needs, including registering fixups, using the EncoderMethod string. For an example, have a look at the

2010/10/21 Jason Kim <jasonwkim at google.com>: > That is exactly what I need - I need a nice MC way to output a at > least two different 4 byte size fields after all of the blobs in the > .ARM.attributes are sent out. Hi Jason, If I got it right, you need to write to the attributes section after you have moved out to print the rest of the file. I can't think of an example

On Jun 22, 2011, at 8:39 AM, Damjan Marion wrote: > > On Jun 22, 2011, at 5:29 PM, Jim Grosbach wrote: > >> >> On Jun 22, 2011, at 7:22 AM, Renato Golin wrote: >> >>> On 22 June 2011 14:33, Damjan Marion <damjan.marion at gmail.com> wrote: >>>> Problem is that in case when old binutils are used (in my case freebsd is using old one due to

On Sep 29, 2010, at 3:09 PM, Jason Kim wrote: > Hi Everyone, > > I am trying to decide on a MC'ized reorg of ARMAsmPrinter for MC/ELF, > and had some questions. > > Currently, it defines quite a few methods like printAddrMode4Operand > (linked to ARMInstrInfo.td) that currently assume raw text support in > the OutStreamer. Are these methods still supposed to be

Hi everyone, I am trying to get up to speed on the MC object file emission for ARM, the first cut being for ELF, and the testing required for that. Obviously, we want the tests for the .o emission to ultimately test the entire .ll -> many llvm passes -> .bc -> .o, but as a first cut, my instinct tells me that a simple .cpp unit tests that directly invokes the MC code to generate (and

On Apr 5, 2011, at 2:56 AM, Viktor Pavlu wrote: > On Mon, Apr 4, 2011 at 9:50 PM, Eric Christopher <echristo at apple.com> wrote: >> >> On Apr 1, 2011, at 6:53 AM, Viktor Pavlu wrote: >> >>> [...] Although most optimizations are turned off >>> already and the FastISel instruction selector is used, the "fast" path >>> for first-time

On Aug 30, 2011, at 3:47 AM, Eli Bendersky wrote: > Hello, > > I'm interested in debugging code JITted by LLVM at runtime. For that, I should naturally have some way to emit DWARF that faithfully describes the JITted code into memory along with the JITted code itself and point the debugger to it. Let's assume that the bridge with the debugger is taken care of (e.g.

Let me see if I understand the response ;-) When you are saying integrated assembler do you mean llc --filetype=obj? If so, we currently have that for an option when running the test-suite. When you say that to test the llvm-mc assembler for your target you don't substitute the gcc assembler invocation for llvm-mc which would expect the resultant executable run to pass. Instead you have to

On Wed, Sep 29, 2010 at 4:00 PM, Jim Grosbach <grosbach at apple.com> wrote: > > On Sep 29, 2010, at 3:58 PM, Anton Korobeynikov wrote: > >> Hi Jim, >> >>> Since this is by definition only for .s file emission, why is this clearly wrong? Perhaps it is, but it's not obvious to me why. >> Attributes should be emitted into object file as well... > >

On 10 January 2011 23:54, Jason Kim <jasonwkim at google.com> wrote: > If I am understanding you correctly, then the answer is no, because .s > output doesn't care about relocations per se... Hi Jason, That's not entirely true. ;) If you only use the GNU toolchain, that is correct. However, CodeSourcery's GCC changed a bit on how it works for ARM because the ARM toolchain

This is most likely user error but I am getting: /a/home/jplevyak/projects/llvm/Debug+Asserts/bin/tblgen: Record `Alias' does not have a field named `AdditionalMembers'! make[5]: *** [/a/home/jplevyak/projects/llvm/tools/clang/include/clang/AST/Debug+Asserts/Attrs.inc.tmp] Error 1 make[5]: Leaving directory `/a/home/jplevyak/projects/llvm/tools/clang/include/clang/AST' While