[llvm-commits] [llvm] r43918 - in /llvm/trunk/lib/Target/X86: X86RegisterInfo.cpp X86RegisterInfo.td

Evan Cheng evan.cheng at apple.com
Fri Nov 9 08:55:16 PST 2007


Since I gave bad advice last time, how about one more advice? :-)

Create a DenseMap mapping from target registers to dwarf numbers at  
X86RegisterInfo ctor (or on demand the first time getDwarfRegNum is  
called). So subsequent queries should be nice and fast.

Frankly I don't think the issue is worth spending this much time on.  
Whatever works and maintainable is good.

Evan

On Nov 9, 2007, at 8:13 AM, Dale Johannesen wrote:

>
> On Nov 8, 2007, at 10:05 PM, Chris Lattner wrote:
>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=43918&view=rev
>>> Log:
>>> Rewrite Dwarf number handling per review comments.
>>
>> Hi Dale,
>>
>> I'm pretty uncomfortable with this, because it means that we're tying
>> down the register order.
>
> I tend to agree, but both comments I got on this patch suggested the
> table approach.
>
> Actually the more I look at other people's suggestions the more I
> like my original patch (43844).
> Compared to your suggestion below, that has 2 switches instead of 3
> and the switches
> are smaller, and it's also proof against reordering of registers.
> What do you think of that one?
>
>> How about something like:
>>
>>   if (Darwin32) {
>>    switch (RegNo) {
>>    case X86::AL: case X86::AH: case X86::AX:  return 0;
>>    case X86::EDI:  ...
>>   } else if (darwin64) {
>>    switch (RegNo) {
>>    ...
>>   } else {
>>   }
>>
>> That way we don't break EH/debug info if registers are reordered or
>> added in the future.
>>
>> -Chris
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits




More information about the llvm-commits mailing list