[llvm] r201937 - Move get[S|U]LEB128Size() to LEB128.h.

Logan Chien tzuhsiang.chien at gmail.com
Sat Feb 22 06:38:54 PST 2014


Sorry for the typo.

"these are depending on every member of MCAsmInfo"

should be:

"these are not depending on any member of MCAsmInfo"


Logan


On Sat, Feb 22, 2014 at 10:37 PM, Logan Chien <tzuhsiang.chien at gmail.com>wrote:

> Hi Rafael,
>
> I moved these functions to LEB128.h because these are depending on every
> member of MCAsmInfo and they are more similar with the function such as
> encodeLEB128().  IMO, it will be better to move them to llvm namespace, so
> that we don't have to call the functions with MCAsmInfo:: prefix.
>
> I have changed these functions to inline functions because the existing
> functions in LEB128.h are inline functions.  Besides, these functions are
> small enough to be inlined.  It you have some concern, I can move the
> function definition to lib/Support/LEB128.cpp.
>
> Sincerely,
> Logan
>
>
> On Sat, Feb 22, 2014 at 10:24 PM, Rafael EspĂ­ndola <
> rafael.espindola at gmail.com> wrote:
>
>> > --- llvm/trunk/include/llvm/Support/LEB128.h (original)
>> > +++ llvm/trunk/include/llvm/Support/LEB128.h Sat Feb 22 08:00:39 2014
>> > @@ -90,6 +90,31 @@ inline uint64_t decodeULEB128(const uint
>> >    return Value;
>> >  }
>> >
>> > +/// Utility function to get the size of the ULEB128-encoded value.
>> > +inline unsigned getULEB128Size(uint64_t Value) {
>> > +  unsigned Size = 0;
>>
>> Why inline? Why in Support? ARMELFStreamer.cpp would have been able to
>> use it from MC.
>>
>> Cheers,
>> Rafael
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140222/afcc31eb/attachment.html>


More information about the llvm-commits mailing list