[cfe-commits] [PATCH]: arm definition of initDwarfEHRegSizeTable

[Eli Friedman]

On Wed, May 18, 2011 at 11:17 AM, Roman Divacky <rdivacky at freebsd.org> wrote:
> On Wed, May 18, 2011 at 11:13:46AM -0700, Eli Friedman wrote:
>> On Wed, May 18, 2011 at 10:55 AM, Roman Divacky <rdivacky at freebsd.org> wrote:
>> > On Wed, May 18, 2011 at 10:25:16AM -0700, Eli Friedman wrote:
>> >> On Wed, May 18, 2011 at 9:40 AM, Roman Divacky <rdivacky at freebsd.org> wrote:
>> >> > OK to commit? It defines 16 registers (0 - 15) to be 32bit.
>> >> > This is necessary for __builtin_init_dwarf_reg_size_table() no arm.
>> >> >
>> >> >
>> >> > Index: lib/CodeGen/TargetInfo.cpp
>> >> > ===================================================================
>> >> > --- lib/CodeGen/TargetInfo.cpp ?(revision 131534)
>> >> > +++ lib/CodeGen/TargetInfo.cpp ?(working copy)
>> >> > @@ -2279,6 +2279,22 @@
>> >> > ? int getDwarfEHStackPointer(CodeGen::CodeGenModule &M) const {
>> >> > ? ? return 13;
>> >> > ? }
>> >> > +
>> >> > + ?bool initDwarfEHRegSizeTable(CodeGen::CodeGenFunction &CGF,
>> >> > + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? llvm::Value *Address) const {
>> >> > + ? ?CodeGen::CGBuilderTy &Builder = CGF.Builder;
>> >> > + ? ?llvm::LLVMContext &Context = CGF.getLLVMContext();
>> >> > +
>> >> > + ? ?const llvm::IntegerType *i8 = llvm::Type::getInt8Ty(Context);
>> >> > + ? ?llvm::Value *Four8 = llvm::ConstantInt::get(i8, 4);
>> >> > +
>> >> > + ? ?// 0-15 are the 16 integer registers.
>> >> > + ? ?AssignToArrayRange(Builder, Address, Four8, 0, 15);
>> >> > +
>> >> > + ? ?return false;
>> >> > + ?}
>> >> > +
>> >> > +
>> >> > ?};
>> >> >
>> >> > ?}
>> >>
>> >> Is this the same thing that gcc generates? ?I can't tell because the
>> >> ARM gcc that I have ICE's on calls to
>> >> __builtin_init_dwarf_reg_size_table().
>> >
>> > It should be, arm has 16 32bit registers, both machine and dwarf numbered
>> > 0 to 15. I didnt test though (dont have arm-gcc). The code itself is copied
>> > from X86_64 definition (with 8 -> 4 change).
>>
>> Well, it doesn't take NEON registers into account... might not be an
>> issue, though.
>
> X86 does not specify its vector/float registers either. PPC does. In either
> case, it can be easily fixed afterwards if it turns out we need that.
>

K... then this looks fine.

-Eli