[llvm-commits] r133216 - in /llvm/trunk: include/llvm/Target/TargetRegisterInfo.h lib/CodeGen/AllocationOrder.cpp lib/CodeGen/RegAllocLinearScan.cpp lib/Target/ARM/ARMBaseRegisterInfo.cpp lib/Target/ARM/ARMBaseRegisterInfo.h

Jakob Stoklund Olesen stoklund at 2pi.dk
Thu Jun 16 17:25:02 PDT 2011


On Jun 16, 2011, at 5:15 PM, Richard Smith wrote:

> Hi,
> 
>> Author: stoklund
>> Date: Thu Jun 16 18:31:16 2011
>> New Revision: 133216
>> 
>> URL: http://llvm.org/viewvc/llvm-project?rev=133216&view=rev
>> Log:
>> Rename TRI::getAllocationOrder() to getRawAllocationOrder().
>> 
>> Also switch the return type to ArrayRef<unsigned> which works out nicely
>> for ARM's implementation of this function because of the clever ArrayRef
>> constructors.
> 
> Unfortunately, they're too clever for g++4.4, which appears to decay the
> array to a pointer before trying the implicit conversion to ArrayRef:
> 
> src/lib/Target/ARM/ARMBaseRegisterInfo.cpp: In member function ‘virtual
> llvm::ArrayRef<unsigned int>
> llvm::ARMBaseRegisterInfo::getRawAllocationOrder(const
> llvm::TargetRegisterClass*, unsigned int, unsigned int, const
> llvm::MachineFunction&) const’:
> src/lib/Target/ARM/ARMBaseRegisterInfo.cpp:482: error: conversion from
> ‘const unsigned int*’ to non-scalar type ‘llvm::ArrayRef<unsigned int>’
> requested
> [etc.]
> 
> See this buildbot:
> 
> http://google1.osuosl.org:8011/builders/llvm-gcc-i686-pc-linux-gnu-cross-arm-eabi-hard-float/builds/4883
> 
> g++4.4 is smart enough to cope with this pattern:
> 
>  return ArrayRef<unsigned>(GPREven1);

Applied in r133220. Thanks!

/jakob





More information about the llvm-commits mailing list