<br><br><div class="gmail_quote">2010/9/15 <span dir="ltr"><<a href="mailto:llvmdev-request@cs.uiuc.edu">llvmdev-request@cs.uiuc.edu</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Send LLVMdev mailing list submissions to<br>
<a href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:llvmdev-request@cs.uiuc.edu">llvmdev-request@cs.uiuc.edu</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:llvmdev-owner@cs.uiuc.edu">llvmdev-owner@cs.uiuc.edu</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of LLVMdev digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: ARM MC .s status? (Jason Kim)<br>
2. tblgen error in svn (John Plevyak)<br>
3. Re: ARM MC .s status? (Jim Grosbach)<br>
4. Re: ARM MC .s status? (Jason Kim)<br>
5. Re: global type legalization? (Bob Wilson)<br>
6. Re: ARM MC .s status? (Jim Grosbach)<br>
7. Thumb categorizing TST wrongly (Gabor Greif)<br>
8. Re: LLVM SVN Repository Offline for Maintenance Tomorrow<br>
(John Criswell)<br>
9. Re: LLVM SVN Repository Offline for Maintenance Tomorrow<br>
(John Criswell)<br>
10. Re: Thumb categorizing TST wrongly (Eric Christopher)<br>
11. Re: Object File Library. llvm-nm changed to match binutils-nm<br>
for COFF and ELF (32, little endian). (Michael Spencer)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Tue, 14 Sep 2010 10:02:55 -0700<br>
From: Jason Kim <<a href="mailto:jasonwkim@google.com">jasonwkim@google.com</a>><br>
Subject: Re: [LLVMdev] ARM MC .s status?<br>
To: Rafael Espindola <<a href="mailto:espindola@google.com">espindola@google.com</a>><br>
Cc: nacl-eng <<a href="mailto:nacl-eng@google.com">nacl-eng@google.com</a>>, <a href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a><br>
Message-ID:<br>
<<a href="mailto:AANLkTim9uxEe%2BktRXr1N2v3f_X7u3q1WQ8Ag5N_YuwLN@mail.gmail.com">AANLkTim9uxEe+ktRXr1N2v3f_X7u3q1WQ8Ag5N_YuwLN@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
Hi everyone, Rafael has graciously given me some pointers for helping<br>
out on the ARM/MC .s emission infrastructure, and I am volunteering to<br>
do so.<br>
It looks like as of yesterday, the MC obj emitter for ARM is also<br>
incomplete (there does not seem to be a ARMMCCodeEmitter.cpp, for<br>
example)<br>
<br>
So if anyone already has started looking into this, I'd like to pool<br>
info so as to not step on toes.<br>
Any add'l tips and pointers would be greatly appreciated.<br>
<br>
Thanks!<br>
-jasonkim<br>
<br>
<br>
On Mon, Sep 13, 2010 at 3:06 PM, Rafael Espindola <<a href="mailto:espindola@google.com">espindola@google.com</a>> wrote:<br>
> On 13 September 2010 17:36, Jason Kim <<a href="mailto:jasonwkim@google.com">jasonwkim@google.com</a>> wrote:<br>
>> Hi Rafael, hope things are well.<br>
>><br>
>> Sehr suggested I ping you briefly on suggestions/ideas/steps for<br>
>> contributing to the MC/ARM code base -<br>
>> Any hints/breadcrumbs would be greatly appreciated.<br>
><br>
> Sure. CCing nacl-eng in case there are others interested too.<br>
><br>
> In the case of ARM the problem is that the assembly printer is still<br>
> just that, it prints assembly. It has to be ported to the MC<br>
> infrastructure that allows different file formats to be supported.<br>
><br>
> There is already a very basic ARM printer that uses MC. It is enabled<br>
> by the option enable-arm-mcinst-printer. ?The task is basically to<br>
> complete it.<br>
><br>
> I would suggest turning that option on by default and checking what<br>
> brakes during "make check-lit" for example. Aborts should be<br>
> particular good in pointing out missing features.<br>
><br>
>> Thanks!<br>
>><br>
>> -jason<br>
>><br>
><br>
> Cheers,<br>
> --<br>
> Rafael ?vila de Esp?ndola<br>
><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Tue, 14 Sep 2010 10:05:17 -0700<br>
From: John Plevyak <<a href="mailto:jplevyak@acm.org">jplevyak@acm.org</a>><br>
Subject: [LLVMdev] tblgen error in svn<br>
To: <a href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a><br>
Message-ID: <<a href="mailto:4C8FAB4D.7080004@acm.org">4C8FAB4D.7080004@acm.org</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
<br>
This is most likely user error but I am getting:<br>
<br>
/a/home/jplevyak/projects/llvm/Debug+Asserts/bin/tblgen: Record `Alias'<br>
does not have a field named `AdditionalMembers'!<br>
<br>
make[5]: ***<br>
[/a/home/jplevyak/projects/llvm/tools/clang/include/clang/AST/Debug+Asserts/Attrs.inc.tmp]<br>
Error 1<br>
make[5]: Leaving directory<br>
`/a/home/jplevyak/projects/llvm/tools/clang/include/clang/AST'<br>
<br>
While building:<br>
<br>
<a href="http://llvm.org/svn/llvm-project/llvm/trunk" target="_blank">http://llvm.org/svn/llvm-project/llvm/trunk</a><br>
<br>
jplevyak:llvm [414] % uname -a<br>
Linux <a href="http://jplevyak.homeip.net" target="_blank">jplevyak.homeip.net</a> 2.6.34.6-47.fc13.x86_64 #1 SMP Fri Aug 27<br>
08:56:01 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux<br>
jplevyak:llvm [415] % gcc -v<br>
Using built-in specs.<br>
Target: x86_64-redhat-linux<br>
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man<br>
--infodir=/usr/share/info<br>
--with-bugurl=<a href="http://bugzilla.redhat.com/bugzilla" target="_blank">http://bugzilla.redhat.com/bugzilla</a> --enable-bootstrap<br>
--enable-shared --enable-threads=posix --enable-checking=release<br>
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions<br>
--enable-gnu-unique-object<br>
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada<br>
--enable-java-awt=gtk --disable-dssi<br>
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre<br>
--enable-libgcj-multifile --enable-java-maintainer-mode<br>
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar<br>
--disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic<br>
--with-arch_32=i686 --build=x86_64-redhat-linux<br>
Thread model: posix<br>
gcc version 4.4.4 20100630 (Red Hat 4.4.4-10) (GCC)<br>
<br>
Any help appreciated.<br>
<br>
john<br>
<br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Tue, 14 Sep 2010 11:08:45 -0700<br>
From: Jim Grosbach <<a href="mailto:grosbach@apple.com">grosbach@apple.com</a>><br>
Subject: Re: [LLVMdev] ARM MC .s status?<br>
To: Jason Kim <<a href="mailto:jasonwkim@google.com">jasonwkim@google.com</a>><br>
Cc: nacl-eng <<a href="mailto:nacl-eng@google.com">nacl-eng@google.com</a>>, LLVM Developers Mailing List<br>
<<a href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a>><br>
Message-ID: <<a href="mailto:9DAD1A8F-0A2A-47FD-A948-83A2E1AD51A6@apple.com">9DAD1A8F-0A2A-47FD-A948-83A2E1AD51A6@apple.com</a>><br>
Content-Type: text/plain; charset=iso-8859-1<br>
<br>
Hi Jason,<br>
<br>
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.<br>
<br>
My current high level plan is something like the following:<br>
<br>
1. MC-ized Assembly Printer<br>
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.<br>
b. Repeat (a) except running the full nightly regression suite, not just "make check."<br>
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).<br>
d. Nuke the old asm printer once the above is complete and enable the MC printer as the One True Printer(tm).<br>
<br>
2. Object File Emission<br>
a. Add basic infrastructure for the object file emitter. i.e. just construct the classes needed and put in lots of asserts() and FIXMEs.<br>
b. Add ARM-specific object file format bits.<br>
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.<br>
<br>
3. JIT. Same basic approach as (1) to replace the current object code emitter with an MC based one.<br>
a. Hand-wavey stuff. I haven't thought much about this bit yet except in broad terms.<br>
b. More hand waving.<br>
<br>
4. ???<br>
<br>
5. Profit.<br>
<br>
-Jim<br>
<br>
On Sep 14, 2010, at 10:02 AM, Jason Kim wrote:<br>
<br>
> Hi everyone, Rafael has graciously given me some pointers for helping<br>
> out on the ARM/MC .s emission infrastructure, and I am volunteering to<br>
> do so.<br>
> It looks like as of yesterday, the MC obj emitter for ARM is also<br>
> incomplete (there does not seem to be a ARMMCCodeEmitter.cpp, for<br>
> example)<br>
><br>
> So if anyone already has started looking into this, I'd like to pool<br>
> info so as to not step on toes.<br>
> Any add'l tips and pointers would be greatly appreciated.<br>
><br>
> Thanks!<br>
> -jasonkim<br>
><br>
><br>
> On Mon, Sep 13, 2010 at 3:06 PM, Rafael Espindola <<a href="mailto:espindola@google.com">espindola@google.com</a>> wrote:<br>
>> On 13 September 2010 17:36, Jason Kim <<a href="mailto:jasonwkim@google.com">jasonwkim@google.com</a>> wrote:<br>
>>> Hi Rafael, hope things are well.<br>
>>><br>
>>> Sehr suggested I ping you briefly on suggestions/ideas/steps for<br>
>>> contributing to the MC/ARM code base -<br>
>>> Any hints/breadcrumbs would be greatly appreciated.<br>
>><br>
>> Sure. CCing nacl-eng in case there are others interested too.<br>
>><br>
>> In the case of ARM the problem is that the assembly printer is still<br>
>> just that, it prints assembly. It has to be ported to the MC<br>
>> infrastructure that allows different file formats to be supported.<br>
>><br>
>> There is already a very basic ARM printer that uses MC. It is enabled<br>
>> by the option enable-arm-mcinst-printer. The task is basically to<br>
>> complete it.<br>
>><br>
>> I would suggest turning that option on by default and checking what<br>
>> brakes during "make check-lit" for example. Aborts should be<br>
>> particular good in pointing out missing features.<br>
>><br>
>>> Thanks!<br>
>>><br>
>>> -jason<br>
>>><br>
>><br>
>> Cheers,<br>
>> --<br>
>> Rafael ?vila de Esp?ndola<br>
>><br>
><br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Tue, 14 Sep 2010 11:26:15 -0700<br>
From: Jason Kim <<a href="mailto:jasonwkim@google.com">jasonwkim@google.com</a>><br>
Subject: Re: [LLVMdev] ARM MC .s status?<br>
To: Jim Grosbach <<a href="mailto:grosbach@apple.com">grosbach@apple.com</a>><br>
Cc: nacl-eng <<a href="mailto:nacl-eng@google.com">nacl-eng@google.com</a>>, LLVM Developers Mailing List<br>
<<a href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a>><br>
Message-ID:<br>
<AANLkTin_uO-Ly9SLQSPHStTmmjF-Z44V5_PLwWEamj=<a href="mailto:i@mail.gmail.com">i@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
Hi Jim!<br>
<br>
On Tue, Sep 14, 2010 at 11:08 AM, Jim Grosbach <<a href="mailto:grosbach@apple.com">grosbach@apple.com</a>> wrote:<br>
> Hi Jason,<br>
><br>
> 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.<br>
<br>
It looks like the MC obj emission and MC .s emission are two naturally<br>
related, but separate tasks. I think the overall goal of having the MC<br>
.s/.o drive the entire flow is probably a great idea. Your plan for<br>
MC.s and MC.o sounds spot on as well. I humbly suggest you tackle the<br>
.s emission, and I tackle the .o emission - I haven't thought about<br>
how this will interact with generating arch-specific .so's directly<br>
from LLVM...<br>
(I am sure there's a blog post about it somewhere on <a href="http://llvm.org" target="_blank">llvm.org</a> :)<br>
<br>
> My current high level plan is something like the following:<br>
><br>
> 1. MC-ized Assembly Printer<br>
> 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.<br>
> b. Repeat (a) except running the full nightly regression suite, not just "make check."<br>
> 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).<br>
> d. Nuke the old asm printer once the above is complete and enable the MC printer as the One True Printer(tm).<br>
<br>
<br>
<br>
> 2. Object File Emission<br>
> a. Add basic infrastructure for the object file emitter. i.e. just construct the classes needed and put in lots of asserts() and FIXMEs.<br>
> b. Add ARM-specific object file format bits.<br>
> 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.<br>
><br>
> 3. JIT. Same basic approach as (1) to replace the current object code emitter with an MC based one.<br>
> a. Hand-wavey stuff. I haven't thought much about this bit yet except in broad terms.<br>
> b. More hand waving.<br>
<br>
Lots of handwavy stuff - fast incremental feedback based optimization <blah><br>
<br>
> 4. ???<br>
><br>
> 5. Profit.<br>
><br>
> -Jim<br>
><br>
> On Sep 14, 2010, at 10:02 AM, Jason Kim wrote:<br>
><br>
>> Hi everyone, Rafael has graciously given me some pointers for helping<br>
>> out on the ARM/MC .s emission infrastructure, and I am volunteering to<br>
>> do so.<br>
>> It looks like as of yesterday, the MC obj emitter for ARM is also<br>
>> incomplete (there does not seem to be a ARMMCCodeEmitter.cpp, for<br>
>> example)<br>
>><br>
>> So if anyone already has started looking into this, I'd like to pool<br>
>> info so as to not step on toes.<br>
>> Any add'l tips and pointers would be greatly appreciated.<br>
>><br>
>> Thanks!<br>
>> -jasonkim<br>
>><br>
>><br>
>> On Mon, Sep 13, 2010 at 3:06 PM, Rafael Espindola <<a href="mailto:espindola@google.com">espindola@google.com</a>> wrote:<br>
>>> On 13 September 2010 17:36, Jason Kim <<a href="mailto:jasonwkim@google.com">jasonwkim@google.com</a>> wrote:<br>
>>>> Hi Rafael, hope things are well.<br>
>>>><br>
>>>> Sehr suggested I ping you briefly on suggestions/ideas/steps for<br>
>>>> contributing to the MC/ARM code base -<br>
>>>> Any hints/breadcrumbs would be greatly appreciated.<br>
>>><br>
>>> Sure. CCing nacl-eng in case there are others interested too.<br>
>>><br>
>>> In the case of ARM the problem is that the assembly printer is still<br>
>>> just that, it prints assembly. It has to be ported to the MC<br>
>>> infrastructure that allows different file formats to be supported.<br>
>>><br>
>>> There is already a very basic ARM printer that uses MC. It is enabled<br>
>>> by the option enable-arm-mcinst-printer. ?The task is basically to<br>
>>> complete it.<br>
>>><br>
>>> I would suggest turning that option on by default and checking what<br>
>>> brakes during "make check-lit" for example. Aborts should be<br>
>>> particular good in pointing out missing features.<br>
>>><br>
>>>> Thanks!<br>
>>>><br>
>>>> -jason<br>
>>>><br>
>>><br>
>>> Cheers,<br>
>>> --<br>
>>> Rafael ?vila de Esp?ndola<br>
>>><br>
>><br>
>> _______________________________________________<br>
>> LLVM Developers mailing list<br>
>> <a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> ? ? ? ? <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
><br>
><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Tue, 14 Sep 2010 11:37:52 -0700<br>
From: Bob Wilson <<a href="mailto:bob.wilson@apple.com">bob.wilson@apple.com</a>><br>
Subject: Re: [LLVMdev] global type legalization?<br>
To: Chris Lattner <<a href="mailto:clattner@apple.com">clattner@apple.com</a>><br>
Cc: LLVM Developers Mailing List <<a href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a>><br>
Message-ID: <<a href="mailto:BE768C68-1D1C-419D-98B0-293F05E4189E@apple.com">BE768C68-1D1C-419D-98B0-293F05E4189E@apple.com</a>><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
Returning to an old discussion here....<br>
<br>
On Aug 18, 2010, at 10:42 AM, Chris Lattner wrote:<br>
<br>
> On Aug 18, 2010, at 10:27 AM, Bob Wilson wrote:<br>
>>> 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.<br>
>><br>
>> 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.<br>
><br>
> The code I'm thinking of is in SelectionDAGISel::ComputeLiveOutVRegInfo<br>
<br>
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.<br>
<br>
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).<br>
<br>
><br>
>> 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.<br>
><br>
> 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.<br>
<br>
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?<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100914/d6d7a9aa/attachment-0001.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100914/d6d7a9aa/attachment-0001.html</a><br>
<br>
------------------------------<br>
<br>
Message: 6<br>
Date: Tue, 14 Sep 2010 11:50:35 -0700<br>
From: Jim Grosbach <<a href="mailto:grosbach@apple.com">grosbach@apple.com</a>><br>
Subject: Re: [LLVMdev] ARM MC .s status?<br>
To: Jason Kim <<a href="mailto:jasonwkim@google.com">jasonwkim@google.com</a>><br>
Cc: LLVM Developers Mailing List <<a href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a>><br>
Message-ID: <<a href="mailto:24E56983-E1D8-444C-9B68-4DD86186EE45@apple.com">24E56983-E1D8-444C-9B68-4DD86186EE45@apple.com</a>><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
<br>
On Sep 14, 2010, at 11:26 AM, Jason Kim wrote:<br>
<br>
> Hi Jim!<br>
><br>
> On Tue, Sep 14, 2010 at 11:08 AM, Jim Grosbach <<a href="mailto:grosbach@apple.com">grosbach@apple.com</a>> wrote:<br>
>> Hi Jason,<br>
>><br>
>> 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.<br>
><br>
> It looks like the MC obj emission and MC .s emission are two naturally<br>
> related, but separate tasks. I think the overall goal of having the MC<br>
> .s/.o drive the entire flow is probably a great idea. Your plan for<br>
> MC.s and MC.o sounds spot on as well. I humbly suggest you tackle the<br>
> .s emission, and I tackle the .o emission<br>
<br>
Sounds perfectly reasonable to me. We can always adjust later if need be for some reason. Looking forward to working with you.<br>
<br>
> - I haven't thought about<br>
> how this will interact with generating arch-specific .so's directly<br>
> from LLVM...<br>
<br>
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.<br>
<br>
<br>
Regards,<br>
Jim<br>
<br>
<br>
------------------------------<br>
<br>
Message: 7<br>
Date: Tue, 14 Sep 2010 21:09:15 +0200<br>
From: Gabor Greif <<a href="mailto:gabor@mac.com">gabor@mac.com</a>><br>
Subject: [LLVMdev] Thumb categorizing TST wrongly<br>
To: LLVM Developers Mailing List <<a href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a>><br>
Message-ID: <<a href="mailto:7EABAC00-FD22-4757-8F8B-9FFEF5AD5767@mac.com">7EABAC00-FD22-4757-8F8B-9FFEF5AD5767@mac.com</a>><br>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed<br>
<br>
I see strangeness on Thumb TST (tTST) predicate 'isCompare'<br>
<br>
It is true for regular ARM, false for Thumb:<br>
<br>
(gdb) p MI->dump()<br>
TSTri %reg16397, 3, pred:14, pred:%reg0, %CPSR<imp-def>; GPR:%<br>
reg16397<br>
$24 = void<br>
(gdb) p MI->getDesc().isCompare()<br>
$25 = true<br>
<br>
<br>
(gdb) p MI->dump()<br>
tTST %reg16396, %reg16397, pred:14, pred:%reg0, %CPSR<imp-def>;<br>
tGPR:%reg16396,16397<br>
$22 = void<br>
(gdb) p MI->getDesc().isCompare()<br>
$23 = false<br>
<br>
<br>
Is this intentional or just an oversight? In latter case how do I fix<br>
it? Tablegen input?<br>
<br>
Thanks and cheers,<br>
<br>
Gabor<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 8<br>
Date: Tue, 14 Sep 2010 14:41:56 -0500<br>
From: John Criswell <<a href="mailto:criswell@illinois.edu">criswell@illinois.edu</a>><br>
Subject: Re: [LLVMdev] LLVM SVN Repository Offline for Maintenance<br>
Tomorrow<br>
To: "<a href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a>" <<a href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a>><br>
Cc: "<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a>" <<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a>><br>
Message-ID: <<a href="mailto:4C8FD004.4090202@illinois.edu">4C8FD004.4090202@illinois.edu</a>><br>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed<br>
<br>
John Criswell wrote:<br>
> Dear All,<br>
><br>
> Just a reminder that the maintenance will be commencing now.<br>
><br>
<br>
Also, I managed to set things up so that you can use svn diff and svn up<br>
but not svn commit (I basically disabled commit access for everyone for<br>
the time being).<br>
<br>
-- John T.<br>
<br>
> -- John T.<br>
><br>
> John Criswell wrote:<br>
><br>
>> Dear LLVMers and Clangers,<br>
>><br>
>> We'll be doing some maintenance on the LLVM repository on Tuesday, Sept.<br>
>> 14 (tomorrow). There were some files committed to the repository that<br>
>> we believe need to be removed from both mainline, the branches, and the<br>
>> revision history.<br>
>><br>
>> The SVN repository will go *off-line* at 7:00 am Central Daylight<br>
>> Savings time on Tuesday. Please do not make any commits after 7 am. I<br>
>> estimate the process will take 4-5 hours to complete.<br>
>><br>
>> All SVN services (including those for Clang, VMKit, Klee, SAFECode,<br>
>> Poolalloc, and a host of others) will be unavailable. Other LLVM<br>
>> services (such as the web server) may go offline as well, although I<br>
>> will try to keep them online if I can do so easily. Mailing lists will<br>
>> remain available throughout the procedure as they are not hosted on<br>
>> <a href="http://llvm.org" target="_blank">llvm.org</a>.<br>
>><br>
>> I will send email to llvmdev when the repository is back online.<br>
>><br>
>> I apologize for the inconvenience, but there's not much I can do about<br>
>> it. If it's any consolation, know that I will be inconvenienced just as<br>
>> much as everyone else.<br>
>><br>
>> -- John T.<br>
>><br>
>> _______________________________________________<br>
>> LLVM Developers mailing list<br>
>> <a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
>><br>
>><br>
><br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 9<br>
Date: Tue, 14 Sep 2010 15:31:35 -0500<br>
From: John Criswell <<a href="mailto:criswell@illinois.edu">criswell@illinois.edu</a>><br>
Subject: Re: [LLVMdev] LLVM SVN Repository Offline for Maintenance<br>
Tomorrow<br>
To: "<a href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a>" <<a href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a>><br>
Cc: "<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a>" <<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a>><br>
Message-ID: <<a href="mailto:4C8FDBA7.4080307@illinois.edu">4C8FDBA7.4080307@illinois.edu</a>><br>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed<br>
<br>
Dear All,<br>
<br>
I have some good news and some bad news.<br>
<br>
The bad news is that my rebuild of the SVN repository hit a small snag.<br>
While I think I have it fixed, I don't think I'll have time to rebuild<br>
it and test it before end of today, so I've enabled commit access again.<br>
<br>
As a favor to me (and other admins that are starting to get involved),<br>
please don't make any commits to test-suite in the next 48 hours. A<br>
change in the release_28 branch of test-suite caused the little hiccup<br>
in my script. Commits to anything else should be fine.<br>
<br>
The good news is that the repositories are now open for commit.<br>
<br>
I'll email llvmdev again if we attempt to do this a second time.<br>
<br>
-- John T.<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 10<br>
Date: Tue, 14 Sep 2010 13:46:48 -0700<br>
From: Eric Christopher <<a href="mailto:echristo@apple.com">echristo@apple.com</a>><br>
Subject: Re: [LLVMdev] Thumb categorizing TST wrongly<br>
To: Gabor Greif <<a href="mailto:gabor@mac.com">gabor@mac.com</a>><br>
Cc: LLVM Developers Mailing List <<a href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a>><br>
Message-ID: <<a href="mailto:1DAF38EE-6F4C-483C-A3CB-63B88A1C6CD4@apple.com">1DAF38EE-6F4C-483C-A3CB-63B88A1C6CD4@apple.com</a>><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
<br>
On Sep 14, 2010, at 12:09 PM, Gabor Greif wrote:<br>
<br>
> I see strangeness on Thumb TST (tTST) predicate 'isCompare'<br>
><br>
> It is true for regular ARM, false for Thumb:<br>
><br>
> (gdb) p MI->dump()<br>
> TSTri %reg16397, 3, pred:14, pred:%reg0, %CPSR<imp-def>; GPR:%<br>
> reg16397<br>
> $24 = void<br>
> (gdb) p MI->getDesc().isCompare()<br>
> $25 = true<br>
><br>
><br>
> (gdb) p MI->dump()<br>
> tTST %reg16396, %reg16397, pred:14, pred:%reg0, %CPSR<imp-def>;<br>
> tGPR:%reg16396,16397<br>
> $22 = void<br>
> (gdb) p MI->getDesc().isCompare()<br>
> $23 = false<br>
><br>
><br>
> Is this intentional or just an oversight? In latter case how do I fix<br>
> it? Tablegen input?<br>
<br>
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).<br>
<br>
-eric<br>
<br>
<br>
------------------------------<br>
<br>
Message: 11<br>
Date: Tue, 14 Sep 2010 16:53:16 -0400<br>
From: Michael Spencer <<a href="mailto:bigcheesegs@gmail.com">bigcheesegs@gmail.com</a>><br>
Subject: Re: [LLVMdev] Object File Library. llvm-nm changed to match<br>
binutils-nm for COFF and ELF (32, little endian).<br>
To: llvmdev <<a href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a>><br>
Message-ID:<br>
<<a href="mailto:AANLkTimYLm0i_0C-%2BQ0sw2yZWx5Ubx5Jea_jYXhFAoUi@mail.gmail.com">AANLkTimYLm0i_0C-+Q0sw2yZWx5Ubx5Jea_jYXhFAoUi@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
I have continued to work on this and now have a working llvm-objdump<br>
-d (object file disassembler). It currently supports both x86 and<br>
x86-64 COFF and ELF, and it would be trivial to add support for other<br>
architectures. Currently the output is not exactly the same as<br>
binutils-objdump -d, and it doesn't display relocation info in the<br>
instructions (so you end up with stuff like "call 0").<br>
<br>
This includes all previous patches because I changed most of them.<br>
Keeping the patches in sync isn't difficult because I use git;<br>
however, it's getting harder to review all this code to get it<br>
committed. I'm going to post the first 3 patches directly to<br>
llvm-commits, but I would appreciate any help that would allow<br>
development of this library to move to trunk, so even taking a brief<br>
look to point out any obvious blockers would help.<br>
<br>
- Michael Spencer<br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: object-file-library-patches.zip<br>
Type: application/zip<br>
Size: 60425 bytes<br>
Desc: not available<br>
Url : <a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100914/d5b8d6db/attachment.zip" target="_blank">http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20100914/d5b8d6db/attachment.zip</a><br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
LLVMdev mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br>
<br>
End of LLVMdev Digest, Vol 75, Issue 32<br>
***************************************<br>
</blockquote></div><br>