llvm dev - Nov 2012 - [LLVMdev] problem trying to write an LLVM register-allocation pass

I tried using this flag and it gave me errors on code that otherwise 
assembles and runs just fine (using the version of Gcra.cpp that Lang 
wrote).  So I'm wondering if I should really be using the flag?  I'm 
using it like this:

llc -verify-machineinstrs -load Debug/lib/P4.so -regalloc=gc xxx.bc

Susan


On 11/15/2012 01:13 PM, Jakob Stoklund Olesen wrote:
>
> On Nov 15, 2012, at 7:53 AM, Susan Horwitz<horwitz at cs.wisc.edu>
> wrote:
>
>> Lang -
>>
>> Attached is a new example for which I still get assembler errors.
>>
>> Susan
>
> Hi Susan,
>
> You should never be getting assembler errors if 'llc
> -verify-machineinstrs' approves of your machine code. It might give
> you better error messages than the assembler.
>
> /jakob
>

Hi Susan,

To my knowledge the verifier doesn't produce false positives with any of
the in-tree allocators. If it is raising an error that is worth
investigating. Is it raising an error on any simple test cases? Can you
share the failing case?

- Lang.


On Thu, Nov 15, 2012 at 2:44 PM, Susan Horwitz <horwitz at cs.wisc.edu>
wrote:
> I tried using this flag and it gave me errors on code that otherwise
> assembles and runs just fine (using the version of Gcra.cpp that Lang
> wrote).  So I'm wondering if I should really be using the flag? 
I'm using
> it like this:
>
> llc -verify-machineinstrs -load Debug/lib/P4.so -regalloc=gc xxx.bc
>
> Susan
>
>
>
> On 11/15/2012 01:13 PM, Jakob Stoklund Olesen wrote:
>
>>
>> On Nov 15, 2012, at 7:53 AM, Susan Horwitz<horwitz at
cs.wisc.edu>
>> wrote:
>>
>>  Lang -
>>>
>>> Attached is a new example for which I still get assembler errors.
>>>
>>> Susan
>>>
>>
>> Hi Susan,
>>
>> You should never be getting assembler errors if 'llc
>> -verify-machineinstrs' approves of your machine code. It might give
>> you better error messages than the assembler.
>>
>> /jakob
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20121115/9cddddf3/attachment.html>

Hi Susan,

Jakob pointed out to me that the Gcra.cpp allocator doesn't record
basic-block live-ins, which are used by the verifier to check correctness.

You can record which variables are live into a basic block with
MachineBasicBlock::addLiveIn(unsigned physReg). I don't know the verifier
well, but if it's using other built in infrastructure for register
allocation then it may not be a good fit for your allocator.

I'll try to find time to look at the example files you sent in the next
couple of days.

Cheers,
Lang.


On Thu, Nov 15, 2012 at 5:21 PM, Susan Horwitz <horwitz at cs.wisc.edu>
wrote:
> Well, now I can't reproduce what I thought I had before (an example
that
> works fine with your code except when using that flag).  I do have a small
> example that works fine with *my* code except when using that flag. 
I've
> attached the source (.c), the assembly that my code produces w/o using the
> "verify" flag (.s), the output of trying to create assembly
*with* the
> "verify" flag (.out), and the .bc file used as input to my
register
> allocator.  If you can identify a problem by looking at these files, that
> would be great!
>
> I can supply my register allocator if you'd like to have it, but it
> involves a number of (longish) files.
>
> Thanks for any insights you can provide on this!
>
> Susan
>
>
>
> On 11/15/2012 06:45 PM, Lang Hames wrote:
>
>> Hi Susan,
>>
>> To my knowledge the verifier doesn't produce false positives with
any of
>> the in-tree allocators. If it is raising an error that is worth
>> investigating. Is it raising an error on any simple test cases? Can you
>> share the failing case?
>>
>> - Lang.
>>
>>
>> On Thu, Nov 15, 2012 at 2:44 PM, Susan Horwitz <horwitz at
cs.wisc.edu
>> <mailto:horwitz at cs.wisc.edu>> wrote:
>>
>>     I tried using this flag and it gave me errors on code that
otherwise
>>     assembles and runs just fine (using the version of Gcra.cpp that
>>     Lang wrote).  So I'm wondering if I should really be using the
flag?
>>       I'm using it like this:
>>
>>     llc -verify-machineinstrs -load Debug/lib/P4.so -regalloc=gc xxx.bc
>>
>>     Susan
>>
>>
>>
>>     On 11/15/2012 01:13 PM, Jakob Stoklund Olesen wrote:
>>
>>
>>         On Nov 15, 2012, at 7:53 AM, Susan Horwitz<horwitz at
cs.wisc.edu
>>         <mailto:horwitz at cs.wisc.edu>>
>>
>>         wrote:
>>
>>             Lang -
>>
>>             Attached is a new example for which I still get assembler
>>             errors.
>>
>>             Susan
>>
>>
>>         Hi Susan,
>>
>>         You should never be getting assembler errors if 'llc
>>         -verify-machineinstrs' approves of your machine code. It
might
>> give
>>         you better error messages than the assembler.
>>
>>         /jakob
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20121115/617a33c7/attachment.html>

On Nov 15, 2012, at 8:04 PM, Lang Hames <lhames at gmail.com> wrote:
> Jakob pointed out to me that the Gcra.cpp allocator doesn't record
basic-block live-ins, which are used by the verifier to check correctness.
> 
> You can record which variables are live into a basic block with
MachineBasicBlock::addLiveIn(unsigned physReg). I don't know the verifier
well, but if it's using other built in infrastructure for register
allocation then it may not be a good fit for your allocator.
To clarify, the live-in lists are not there for the verifier's benefit. They
are used by various post-RA passes that care about register liveness, so they
are required to be correct.

/jakob

Lang -

I used addLiveIn and that fixed almost all of the problems with the verify
flag, including the example I sent previously, so no need to look into
that.  I still have a few cases where I'm getting "verify" errors,
though
they don't seem to affect the correctness of the final code.  I will send
an example ASAP.

Thanks for all your help!

Susan
> Hi Susan,
>
> Jakob pointed out to me that the Gcra.cpp allocator doesn't record
> basic-block live-ins, which are used by the verifier to check correctness.
>
> You can record which variables are live into a basic block with
> MachineBasicBlock::addLiveIn(unsigned physReg). I don't know the
verifier
> well, but if it's using other built in infrastructure for register
> allocation then it may not be a good fit for your allocator.
>
> I'll try to find time to look at the example files you sent in the next
> couple of days.
>
> Cheers,
> Lang.
>
>
> On Thu, Nov 15, 2012 at 5:21 PM, Susan Horwitz <horwitz at
cs.wisc.edu>
> wrote:
>
>> Well, now I can't reproduce what I thought I had before (an example
that
>> works fine with your code except when using that flag).  I do have a
>> small
>> example that works fine with *my* code except when using that flag.
>> I've
>> attached the source (.c), the assembly that my code produces w/o using
>> the
>> "verify" flag (.s), the output of trying to create assembly
*with* the
>> "verify" flag (.out), and the .bc file used as input to my
register
>> allocator.  If you can identify a problem by looking at these files,
>> that
>> would be great!
>>
>> I can supply my register allocator if you'd like to have it, but it
>> involves a number of (longish) files.
>>
>> Thanks for any insights you can provide on this!
>>
>> Susan
>>
>>
>>
>> On 11/15/2012 06:45 PM, Lang Hames wrote:
>>
>>> Hi Susan,
>>>
>>> To my knowledge the verifier doesn't produce false positives
with any
>>> of
>>> the in-tree allocators. If it is raising an error that is worth
>>> investigating. Is it raising an error on any simple test cases? Can
you
>>> share the failing case?
>>>
>>> - Lang.
>>>
>>>
>>> On Thu, Nov 15, 2012 at 2:44 PM, Susan Horwitz <horwitz at
cs.wisc.edu
>>> <mailto:horwitz at cs.wisc.edu>> wrote:
>>>
>>>     I tried using this flag and it gave me errors on code that
>>> otherwise
>>>     assembles and runs just fine (using the version of Gcra.cpp
that
>>>     Lang wrote).  So I'm wondering if I should really be using
the
>>> flag?
>>>       I'm using it like this:
>>>
>>>     llc -verify-machineinstrs -load Debug/lib/P4.so -regalloc=gc
xxx.bc
>>>
>>>     Susan
>>>
>>>
>>>
>>>     On 11/15/2012 01:13 PM, Jakob Stoklund Olesen wrote:
>>>
>>>
>>>         On Nov 15, 2012, at 7:53 AM, Susan Horwitz<horwitz at
cs.wisc.edu
>>>         <mailto:horwitz at cs.wisc.edu>>
>>>
>>>         wrote:
>>>
>>>             Lang -
>>>
>>>             Attached is a new example for which I still get
assembler
>>>             errors.
>>>
>>>             Susan
>>>
>>>
>>>         Hi Susan,
>>>
>>>         You should never be getting assembler errors if 'llc
>>>         -verify-machineinstrs' approves of your machine code.
It might
>>> give
>>>         you better error messages than the assembler.
>>>
>>>         /jakob
>>>
>>>
>>>
>>>
>>
>

I have a new problem: Register RBP is used in a function foo.  (I am not 
allocating RBP to any virtual register, the instances of RBP in function 
foo are in the machine code when my register allocator starts.)

Function foo calls function bar.  Register RBP is not saved across the 
call, though it is live after the call.  Function bar includes a virtual 
register.  The code that I'm using to find the registers available to be 
allocated to that virtual register includes EBP in that available-preg 
set.  This is a disaster, since writing into EBP clobbers RBP.

I tried to add code to save all live physical registers across calls, 
but I don't know how to get the appropriate TargetRegisterClass (needed 
to call CreateSpillStackObject).

Is there a different way to save/restore RBP across calls?  Or a way to 
get its TargetRegisterClass?

Susan