2010/9/15 <llvmdev-request at cs.uiuc.edu>
> Send LLVMdev mailing list submissions to
> llvmdev at cs.uiuc.edu
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> or, via email, send a message with subject or body 'help' to
> llvmdev-request at cs.uiuc.edu
>
> You can reach the person managing the list at
> llvmdev-owner at cs.uiuc.edu
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of LLVMdev digest..."
>
>
> Today's Topics:
>
> 1. Re: ARM MC .s status? (Jason Kim)
> 2. tblgen error in svn (John Plevyak)
> 3. Re: ARM MC .s status? (Jim Grosbach)
> 4. Re: ARM MC .s status? (Jason Kim)
> 5. Re: global type legalization? (Bob Wilson)
> 6. Re: ARM MC .s status? (Jim Grosbach)
> 7. Thumb categorizing TST wrongly (Gabor Greif)
> 8. Re: LLVM SVN Repository Offline for Maintenance Tomorrow
> (John Criswell)
> 9. Re: LLVM SVN Repository Offline for Maintenance Tomorrow
> (John Criswell)
> 10. Re: Thumb categorizing TST wrongly (Eric Christopher)
> 11. Re: Object File Library. llvm-nm changed to match binutils-nm
> for COFF and ELF (32, little endian). (Michael Spencer)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 14 Sep 2010 10:02:55 -0700
> From: Jason Kim <jasonwkim at google.com>
> Subject: Re: [LLVMdev] ARM MC .s status?
> To: Rafael Espindola <espindola at google.com>
> Cc: nacl-eng <nacl-eng at google.com>, llvmdev at cs.uiuc.edu
> Message-ID:
> <AANLkTim9uxEe+ktRXr1N2v3f_X7u3q1WQ8Ag5N_YuwLN at
mail.gmail.com<AANLkTim9uxEe%2BktRXr1N2v3f_X7u3q1WQ8Ag5N_YuwLN at
mail.gmail.com>
> >
> Content-Type: text/plain; charset=ISO-8859-1
>
> 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 add'l tips and pointers would be greatly appreciated.
>
> Thanks!
> -jasonkim
>
>
> On Mon, Sep 13, 2010 at 3:06 PM, Rafael Espindola <espindola at
google.com>
> wrote:
> > On 13 September 2010 17:36, Jason Kim <jasonwkim at google.com>
wrote:
> >> Hi Rafael, hope things are well.
> >>
> >> Sehr suggested I ping you briefly on suggestions/ideas/steps for
> >> contributing to the MC/ARM code base -
> >> Any hints/breadcrumbs would be greatly appreciated.
> >
> > Sure. CCing nacl-eng in case there are others interested too.
> >
> > In the case of ARM the problem is that the assembly printer is still
> > just that, it prints assembly. It has to be ported to the MC
> > infrastructure that allows different file formats to be supported.
> >
> > There is already a very basic ARM printer that uses MC. It is enabled
> > by the option enable-arm-mcinst-printer. ?The task is basically to
> > complete it.
> >
> > I would suggest turning that option on by default and checking what
> > brakes during "make check-lit" for example. Aborts should be
> > particular good in pointing out missing features.
> >
> >> Thanks!
> >>
> >> -jason
> >>
> >
> > Cheers,
> > --
> > Rafael ?vila de Esp?ndola
> >
>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 14 Sep 2010 10:05:17 -0700
> From: John Plevyak <jplevyak at acm.org>
> Subject: [LLVMdev] tblgen error in svn
> To: llvmdev at cs.uiuc.edu
> Message-ID: <4C8FAB4D.7080004 at acm.org>
> Content-Type: text/plain; charset=ISO-8859-1
>
>
> 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 building:
>
> http://llvm.org/svn/llvm-project/llvm/trunk
>
> jplevyak:llvm [414] % uname -a
> Linux jplevyak.homeip.net 2.6.34.6-47.fc13.x86_64 #1 SMP Fri Aug 27
> 08:56:01 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux
> jplevyak:llvm [415] % gcc -v
> Using built-in specs.
> Target: x86_64-redhat-linux
> Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
> --infodir=/usr/share/info
> --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap
> --enable-shared --enable-threads=posix --enable-checking=release
> --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
> --enable-gnu-unique-object
> --enable-languages=c,c++,objc,obj-c++,java,fortran,ada
> --enable-java-awt=gtk --disable-dssi
> --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
> --enable-libgcj-multifile --enable-java-maintainer-mode
> --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
> --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic
> --with-arch_32=i686 --build=x86_64-redhat-linux
> Thread model: posix
> gcc version 4.4.4 20100630 (Red Hat 4.4.4-10) (GCC)
>
> Any help appreciated.
>
> john
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 14 Sep 2010 11:08:45 -0700
> From: Jim Grosbach <grosbach at apple.com>
> Subject: Re: [LLVMdev] ARM MC .s status?
> To: Jason Kim <jasonwkim at google.com>
> Cc: nacl-eng <nacl-eng at google.com>, LLVM Developers Mailing
List
> <llvmdev at cs.uiuc.edu>
> Message-ID: <9DAD1A8F-0A2A-47FD-A948-83A2E1AD51A6 at apple.com>
> Content-Type: text/plain; charset=iso-8859-1
>
> 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 working properly.
>
> My current high level plan is something like the following:
>
> 1. MC-ized Assembly Printer
> a. Work through the "make check" failures using the MC inst
printer. Some
> of these are false failures due to mnemonic choice differences, but most
are
> real failures.
> b. Repeat (a) except running the full nightly regression suite, not just
> "make check."
> c. Clean up the printer and instruction lowering code to make much less use
> of the "Modifier" string (which causes lots of tight coupling
between the
> instruction selection code and the asm printer).
> d. Nuke the old asm printer once the above is complete and enable the MC
> printer as the One True Printer(tm).
>
> 2. Object File Emission
> a. Add basic infrastructure for the object file emitter. i.e. just
> construct the classes needed and put in lots of asserts() and FIXMEs.
> b. Add ARM-specific object file format bits.
> c. Run through the test suite using the object file emitter, disassembling
> the output and comparing it to what comes out from the
> .s->assembler->disassembler execution path. Crush all differences.
>
> 3. JIT. Same basic approach as (1) to replace the current object code
> emitter with an MC based one.
> a. Hand-wavey stuff. I haven't thought much about this bit yet except
in
> broad terms.
> b. More hand waving.
>
> 4. ???
>
> 5. Profit.
>
> -Jim
>
> On Sep 14, 2010, at 10:02 AM, Jason Kim wrote:
>
> > 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 add'l tips and pointers would be greatly appreciated.
> >
> > Thanks!
> > -jasonkim
> >
> >
> > On Mon, Sep 13, 2010 at 3:06 PM, Rafael Espindola <espindola at
google.com>
> wrote:
> >> On 13 September 2010 17:36, Jason Kim <jasonwkim at
google.com> wrote:
> >>> Hi Rafael, hope things are well.
> >>>
> >>> Sehr suggested I ping you briefly on suggestions/ideas/steps
for
> >>> contributing to the MC/ARM code base -
> >>> Any hints/breadcrumbs would be greatly appreciated.
> >>
> >> Sure. CCing nacl-eng in case there are others interested too.
> >>
> >> In the case of ARM the problem is that the assembly printer is
still
> >> just that, it prints assembly. It has to be ported to the MC
> >> infrastructure that allows different file formats to be supported.
> >>
> >> There is already a very basic ARM printer that uses MC. It is
enabled
> >> by the option enable-arm-mcinst-printer. The task is basically to
> >> complete it.
> >>
> >> I would suggest turning that option on by default and checking
what
> >> brakes during "make check-lit" for example. Aborts
should be
> >> particular good in pointing out missing features.
> >>
> >>> Thanks!
> >>>
> >>> -jason
> >>>
> >>
> >> Cheers,
> >> --
> >> Rafael ?vila de Esp?ndola
> >>
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 14 Sep 2010 11:26:15 -0700
> From: Jason Kim <jasonwkim at google.com>
> Subject: Re: [LLVMdev] ARM MC .s status?
> To: Jim Grosbach <grosbach at apple.com>
> Cc: nacl-eng <nacl-eng at google.com>, LLVM Developers Mailing
List
> <llvmdev at cs.uiuc.edu>
> Message-ID:
> <AANLkTin_uO-Ly9SLQSPHStTmmjF-Z44V5_PLwWEamj=i at
mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> 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 suggestions
> there, too, as I know they're both very interested in getting this
stuff
> fleshed out and working properly.
>
> It looks like the MC obj emission and MC .s emission are two naturally
> related, but separate tasks. I think the overall goal of having the MC
> .s/.o drive the entire flow is probably a great idea. Your plan for
> MC.s and MC.o sounds spot on as well. I humbly suggest you tackle the
> .s emission, and I tackle the .o emission - I haven't thought about
> how this will interact with generating arch-specific .so's directly
> from LLVM...
> (I am sure there's a blog post about it somewhere on llvm.org :)
>
> > My current high level plan is something like the following:
> >
> > 1. MC-ized Assembly Printer
> > a. Work through the "make check" failures using the MC inst
printer. Some
> of these are false failures due to mnemonic choice differences, but most
are
> real failures.
> > b. Repeat (a) except running the full nightly regression suite, not
just
> "make check."
> > c. Clean up the printer and instruction lowering code to make much
less
> use of the "Modifier" string (which causes lots of tight coupling
between
> the instruction selection code and the asm printer).
> > d. Nuke the old asm printer once the above is complete and enable the
MC
> printer as the One True Printer(tm).
>
>
>
> > 2. Object File Emission
> > a. Add basic infrastructure for the object file emitter. i.e. just
> construct the classes needed and put in lots of asserts() and FIXMEs.
> > b. Add ARM-specific object file format bits.
> > c. Run through the test suite using the object file emitter,
> disassembling the output and comparing it to what comes out from the
> .s->assembler->disassembler execution path. Crush all differences.
> >
> > 3. JIT. Same basic approach as (1) to replace the current object code
> emitter with an MC based one.
> > a. Hand-wavey stuff. I haven't thought much about this bit yet
except in
> broad terms.
> > b. More hand waving.
>
> Lots of handwavy stuff - fast incremental feedback based optimization
> <blah>
>
> > 4. ???
> >
> > 5. Profit.
> >
> > -Jim
> >
> > On Sep 14, 2010, at 10:02 AM, Jason Kim wrote:
> >
> >> 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 add'l tips and pointers would be greatly appreciated.
> >>
> >> Thanks!
> >> -jasonkim
> >>
> >>
> >> On Mon, Sep 13, 2010 at 3:06 PM, Rafael Espindola <espindola at
google.com>
> wrote:
> >>> On 13 September 2010 17:36, Jason Kim <jasonwkim at
google.com> wrote:
> >>>> Hi Rafael, hope things are well.
> >>>>
> >>>> Sehr suggested I ping you briefly on
suggestions/ideas/steps for
> >>>> contributing to the MC/ARM code base -
> >>>> Any hints/breadcrumbs would be greatly appreciated.
> >>>
> >>> Sure. CCing nacl-eng in case there are others interested too.
> >>>
> >>> In the case of ARM the problem is that the assembly printer is
still
> >>> just that, it prints assembly. It has to be ported to the MC
> >>> infrastructure that allows different file formats to be
supported.
> >>>
> >>> There is already a very basic ARM printer that uses MC. It is
enabled
> >>> by the option enable-arm-mcinst-printer. ?The task is
basically to
> >>> complete it.
> >>>
> >>> I would suggest turning that option on by default and checking
what
> >>> brakes during "make check-lit" for example. Aborts
should be
> >>> particular good in pointing out missing features.
> >>>
> >>>> Thanks!
> >>>>
> >>>> -jason
> >>>>
> >>>
> >>> Cheers,
> >>> --
> >>> Rafael ?vila de Esp?ndola
> >>>
> >>
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu
> >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >
> >
>
>
>
> ------------------------------
>
> Message: 5
> Date: Tue, 14 Sep 2010 11:37:52 -0700
> From: Bob Wilson <bob.wilson at apple.com>
> Subject: Re: [LLVMdev] global type legalization?
> To: Chris Lattner <clattner at apple.com>
> Cc: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
> Message-ID: <BE768C68-1D1C-419D-98B0-293F05E4189E at apple.com>
> Content-Type: text/plain; charset="us-ascii"
>
> Returning to an old discussion here....
>
> On Aug 18, 2010, at 10:42 AM, Chris Lattner wrote:
>
> > On Aug 18, 2010, at 10:27 AM, Bob Wilson wrote:
> >>> I tend to think that it isn't worth the compile time to
try to
> microoptimize out every compare, but I could be convinced otherwise if
there
> are important use cases we're failing to handle. I also do think that
> whole-function selection dags will solve a lot of grossness (e.g. much of
> codegen prepare) with a very clean model.
> >>
> >> I'll take a look at Machine CSE and Machine Sink. Where is
the
> heuristic for tracking live-out vregs that you mention? I'm definitely
> seeing a reextend of an already extended value. Worse, the value is
spilled
> and the zext is not folded into the reload.
> >
> > The code I'm thinking of is in
SelectionDAGISel::ComputeLiveOutVRegInfo
>
> For the testcase I'm looking at, ComputeLiveOutVRegInfo does not help
> because it is called prior to selection when the load is an
"any_ext" load.
> It gets (arbitrarily) selected to LDRB, which zero-extends to 32 bits, but
> that's too late to affect the live-out info.
>
> MachineCSE and MachineSink do not help because the first zero-extend is
> folded into the load (LDRB), so the redundant zero-extend (UXTB) does not
> appear to be a CSE. In another case, the zero-extend is also folded into
an
> add (UXTAB), which prevents the add from being selected to a better
> alternative (UXTAB does not allow immediate operands).
>
> >
> >> For ARM and possibly other RISC-like targets, you simply can't
define an
> i8 or i16 value -- those aren't legal types. Since those values will
always
> be extended at the point where they are defined, the code placement problem
> is straightforward: you always want to fold the extends into the def, as
> long as the value is always extended the same way (not mixed sign and zero
> extends). Whole function selection DAGs would make that easy.
> >
> > Right. This is a bit trickier than you make it sound though, because
an
> "i8" addition isn't neccessarily zero or sign extended when
the add is done
> in a 32-bit register.
>
> When you pointed this out earlier, I conceded that I was wrong, but on
> second thought, I'm surprised that llvm uses i8 adds. Other compilers
that
> I've worked on rely on the integral promotion rules for C/C++ to
convert all
> integer arithmetic to the default "int" or "unsigned"
type. That tends to
> work out nicely for register-oriented targets. Is there a reason why llvm
> does not take that approach?
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
>
http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100914/d6d7a9aa/attachment-0001.html
>
> ------------------------------
>
> Message: 6
> Date: Tue, 14 Sep 2010 11:50:35 -0700
> From: Jim Grosbach <grosbach at apple.com>
> Subject: Re: [LLVMdev] ARM MC .s status?
> To: Jason Kim <jasonwkim at google.com>
> Cc: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
> Message-ID: <24E56983-E1D8-444C-9B68-4DD86186EE45 at apple.com>
> Content-Type: text/plain; charset=us-ascii
>
>
> 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 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 working properly.
> >
> > It looks like the MC obj emission and MC .s emission are two naturally
> > related, but separate tasks. I think the overall goal of having the MC
> > .s/.o drive the entire flow is probably a great idea. Your plan for
> > MC.s and MC.o sounds spot on as well. I humbly suggest you tackle the
> > .s emission, and I tackle the .o emission
>
> Sounds perfectly reasonable to me. We can always adjust later if need be
> for some reason. Looking forward to working with you.
>
> > - I haven't thought about
> > how this will interact with generating arch-specific .so's
directly
> > from LLVM...
>
> Semi off the top of my head, I'd expect the normal code path for that
to
> still go through the linker rather than being emitted directly. If nothing
> else, to resolve any symbols that need to be brought in from static libs.
> That said, in combination with the LTO and perhaps some additional
> restrictions (no static symbol dependencies, etc.), I don't see any
reason
> why there couldn't be a .so emitter.
>
>
> Regards,
> Jim
>
>
> ------------------------------
>
> Message: 7
> Date: Tue, 14 Sep 2010 21:09:15 +0200
> From: Gabor Greif <gabor at mac.com>
> Subject: [LLVMdev] Thumb categorizing TST wrongly
> To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
> Message-ID: <7EABAC00-FD22-4757-8F8B-9FFEF5AD5767 at mac.com>
> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
>
> 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
> $22 = void
> (gdb) p MI->getDesc().isCompare()
> $23 = false
>
>
> Is this intentional or just an oversight? In latter case how do I fix
> it? Tablegen input?
>
> Thanks and cheers,
>
> Gabor
>
>
>
> ------------------------------
>
> Message: 8
> Date: Tue, 14 Sep 2010 14:41:56 -0500
> From: John Criswell <criswell at illinois.edu>
> Subject: Re: [LLVMdev] LLVM SVN Repository Offline for Maintenance
> Tomorrow
> To: "llvmdev at cs.uiuc.edu" <llvmdev at cs.uiuc.edu>
> Cc: "cfe-dev at cs.uiuc.edu" <cfe-dev at cs.uiuc.edu>
> Message-ID: <4C8FD004.4090202 at illinois.edu>
> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
>
> John Criswell wrote:
> > Dear All,
> >
> > Just a reminder that the maintenance will be commencing now.
> >
>
> Also, I managed to set things up so that you can use svn diff and svn up
> but not svn commit (I basically disabled commit access for everyone for
> the time being).
>
> -- John T.
>
> > -- John T.
> >
> > John Criswell wrote:
> >
> >> Dear LLVMers and Clangers,
> >>
> >> We'll be doing some maintenance on the LLVM repository on
Tuesday, Sept.
> >> 14 (tomorrow). There were some files committed to the repository
that
> >> we believe need to be removed from both mainline, the branches,
and the
> >> revision history.
> >>
> >> The SVN repository will go *off-line* at 7:00 am Central Daylight
> >> Savings time on Tuesday. Please do not make any commits after 7
am. I
> >> estimate the process will take 4-5 hours to complete.
> >>
> >> All SVN services (including those for Clang, VMKit, Klee,
SAFECode,
> >> Poolalloc, and a host of others) will be unavailable. Other LLVM
> >> services (such as the web server) may go offline as well, although
I
> >> will try to keep them online if I can do so easily. Mailing lists
will
> >> remain available throughout the procedure as they are not hosted
on
> >> llvm.org.
> >>
> >> I will send email to llvmdev when the repository is back online.
> >>
> >> I apologize for the inconvenience, but there's not much I can
do about
> >> it. If it's any consolation, know that I will be
inconvenienced just as
> >> much as everyone else.
> >>
> >> -- John T.
> >>
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >>
> >>
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >
>
>
>
> ------------------------------
>
> Message: 9
> Date: Tue, 14 Sep 2010 15:31:35 -0500
> From: John Criswell <criswell at illinois.edu>
> Subject: Re: [LLVMdev] LLVM SVN Repository Offline for Maintenance
> Tomorrow
> To: "llvmdev at cs.uiuc.edu" <llvmdev at cs.uiuc.edu>
> Cc: "cfe-dev at cs.uiuc.edu" <cfe-dev at cs.uiuc.edu>
> Message-ID: <4C8FDBA7.4080307 at illinois.edu>
> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
>
> Dear All,
>
> I have some good news and some bad news.
>
> The bad news is that my rebuild of the SVN repository hit a small snag.
> While I think I have it fixed, I don't think I'll have time to
rebuild
> it and test it before end of today, so I've enabled commit access
again.
>
> As a favor to me (and other admins that are starting to get involved),
> please don't make any commits to test-suite in the next 48 hours. A
> change in the release_28 branch of test-suite caused the little hiccup
> in my script. Commits to anything else should be fine.
>
> The good news is that the repositories are now open for commit.
>
> I'll email llvmdev again if we attempt to do this a second time.
>
> -- John T.
>
>
>
> ------------------------------
>
> Message: 10
> Date: Tue, 14 Sep 2010 13:46:48 -0700
> From: Eric Christopher <echristo at apple.com>
> Subject: Re: [LLVMdev] Thumb categorizing TST wrongly
> To: Gabor Greif <gabor at mac.com>
> Cc: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
> Message-ID: <1DAF38EE-6F4C-483C-A3CB-63B88A1C6CD4 at apple.com>
> Content-Type: text/plain; charset=us-ascii
>
>
> 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) p MI->dump()
> > tTST %reg16396, %reg16397, pred:14, pred:%reg0,
%CPSR<imp-def>;
> > tGPR:%reg16396,16397
> > $22 = void
> > (gdb) p MI->getDesc().isCompare()
> > $23 = false
> >
> >
> > Is this intentional or just an oversight? In latter case how do I fix
> > it? Tablegen input?
>
> Oversight I think, and it needs to be fixed with isCompare around the
> relevant patterns (ARM mode doesn't see this since isCompare is in the
> multiclass).
>
> -eric
>
>
> ------------------------------
>
> Message: 11
> Date: Tue, 14 Sep 2010 16:53:16 -0400
> From: Michael Spencer <bigcheesegs at gmail.com>
> Subject: Re: [LLVMdev] Object File Library. llvm-nm changed to match
> binutils-nm for COFF and ELF (32, little endian).
> To: llvmdev <llvmdev at cs.uiuc.edu>
> Message-ID:
> <AANLkTimYLm0i_0C-+Q0sw2yZWx5Ubx5Jea_jYXhFAoUi at
mail.gmail.com<AANLkTimYLm0i_0C-%2BQ0sw2yZWx5Ubx5Jea_jYXhFAoUi at
mail.gmail.com>
> >
> Content-Type: text/plain; charset="utf-8"
>
> I have continued to work on this and now have a working llvm-objdump
> -d (object file disassembler). It currently supports both x86 and
> x86-64 COFF and ELF, and it would be trivial to add support for other
> architectures. Currently the output is not exactly the same as
> binutils-objdump -d, and it doesn't display relocation info in the
> instructions (so you end up with stuff like "call 0").
>
> This includes all previous patches because I changed most of them.
> Keeping the patches in sync isn't difficult because I use git;
> however, it's getting harder to review all this code to get it
> committed. I'm going to post the first 3 patches directly to
> llvm-commits, but I would appreciate any help that would allow
> development of this library to move to trunk, so even taking a brief
> look to point out any obvious blockers would help.
>
> - Michael Spencer
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: object-file-library-patches.zip
> Type: application/zip
> Size: 60425 bytes
> Desc: not available
> Url :
>
http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100914/d5b8d6db/attachment.zip
>
> ------------------------------
>
> _______________________________________________
> LLVMdev mailing list
> LLVMdev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
> End of LLVMdev Digest, Vol 75, Issue 32
> ***************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20100915/995739a5/attachment.html>
