<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 25, 2015 at 6:20 AM, Simon Atanasyan <span dir="ltr"><<a href="mailto:simon@atanasyan.com" target="_blank">simon@atanasyan.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Tue, Mar 24, 2015 at 8:57 PM, Simon Atanasyan <<a href="mailto:simon@atanasyan.com">simon@atanasyan.com</a>> wrote:<br>
> On Tue, Mar 24, 2015 at 8:51 PM, Shankar Easwaran<br>
> <<a href="mailto:shankare@codeaurora.org">shankare@codeaurora.org</a>> wrote:<br>
>> On 3/24/2015 12:41 PM, Simon Atanasyan wrote:<br>
>>><br>
>>> On Tue, Mar 24, 2015 at 8:35 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br>
>>>><br>
>>>> On Tue, Mar 24, 2015 at 10:28 AM, Simon Atanasyan <<a href="mailto:simon@atanasyan.com">simon@atanasyan.com</a>><br>
>>>> wrote:<br>
>>>>><br>
>>>>> On Tue, Mar 24, 2015 at 7:16 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>><br>
>>>>> wrote:<br>
>>>>>><br>
>>>>>> On Tue, Mar 24, 2015 at 8:49 AM, Simon Atanasyan <<a href="mailto:simon@atanasyan.com">simon@atanasyan.com</a>><br>
>>>>>> wrote:<br>
>>>>>>><br>
>>>>>>> Author: atanasyan<br>
>>>>>>> Date: Tue Mar 24 10:49:59 2015<br>
>>>>>>> New Revision: 233088<br>
>>>>>>><br>
>>>>>>> URL: <a href="http://llvm.org/viewvc/llvm-project?rev=233088&view=rev" target="_blank">http://llvm.org/viewvc/llvm-project?rev=233088&view=rev</a><br>
>>>>>>> Log:<br>
>>>>>>> [Mips] Suppress "right shift by too large amount" warning<br>
>>>>>>><br>
>>>>>>> Visual C++ shows the "right shift by too large amount" warning if<br>
>>>>>>> `MipsELFReference` is instantiated for 32-bit target and<br>
>>>>>>> `Elf_Rel_Impl::getType`<br>
>>>>>>> method has `unsigned char` return type. We can freely suppress the<br>
>>>>>>> warning<br>
>>>>>>> in<br>
>>>>>>> that case because MIPS 32-bit ABI does not pack multiple relocation<br>
>>>>>>> types<br>
>>>>>>> into<br>
>>>>>>> the single field `r_type` and the `MipsELFReference::_tag` should be<br>
>>>>>>> always<br>
>>>>>>> zero in that case.<br>
>>>>>><br>
>>>>>><br>
>>>>>> Can we just disable the MSVC warning if it's wrong, then?<br>
>>>>><br>
>>>>> I thought about an alternative solution - fix Elf_Rel_Impl::getType()<br>
>>>>> method so all its variants have the same return type uint32_t. Any<br>
>>>>> objections against this idea?<br>
>>>><br>
>>>> It still doesn't seem to improve anything - if getType() still only<br>
>>>> returns<br>
>>>> a number 0-255, the shift still is a zero-ing action. Hiding it from the<br>
>>>> compiler doesn't seem to change anything in the semantics of the<br>
>>>> operation &<br>
>>>> just obscures things further... seems to me, at least.<br>
>>><br>
>>> The getType() does not always return 0-255. In case of 32-bit variant<br>
>>> of Elf_Rel_Impl it does. In case of 64-bit variant it returns 32-bit<br>
>>> integer which can be split up to four parts. In my case I extract<br>
>>> lower 8 bits and high 24 bits.<br>
>><br>
>> Could you use the r_info (getRInfo) field and extract the needed<br>
>> information, seems that is what you need ?<br>
><br>
> Nice. I think it is the best solution for the problem.<br>
<br>
</div></div>I hope the problem has been fixed by r233186. Unfortunately using<br>
getRInfo does not solve the problem because in 32-bit case we extract<br>
too much data and touch symbol index part of r_info field.<br>
<br>
So I just factor out the code that gets the "tag" into the separate<br>
function. That allows to keep all bit manipulation code into the<br>
single place and removes the warning.<br></blockquote><div><br>This (to me - though lld isn't my project, etc) just seems to complicate the code further - what's the point of &ing the 0xFFFFFF00 mask if you're just shifting down 8 anyway? This hides the issue from the compiler because the bitwise & does integer promotion (so the char is promoted to int, then and-ed, then shifted, so the shift is over an int instead of a char) but produces exactly the same result & now makes the optimizer (& reader) do a bit more work?<br><br>- David<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Simon Atanasyan<br>
</font></span></blockquote></div><br></div></div>