This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Fix PR92462


On 11/18/19 3:37 AM, Richard Biener wrote:
> On Mon, 18 Nov 2019, Jakub Jelinek wrote:
> 
>> On Mon, Nov 18, 2019 at 11:07:22AM +0100, Richard Biener wrote:
>>> On Mon, 18 Nov 2019, Jakub Jelinek wrote:
>>>
>>>> On Mon, Nov 18, 2019 at 10:44:14AM +0100, Richard Biener wrote:
>>>>> The following adjusts the find_base_{term,value} heuristic when
>>>>> looking through ANDs to the case where it is obviously not
>>>>> aligning a base (when the LSB is set).
>>>>
>>>> What is specific about the LSB?  I mean & 2 is obviously not an aligning
>>>> AND either.
>>>
>>> It aligns 0x1 and 0x3 ;)
>>>
>>>> Shouldn't we recurse only if the CONST_INT_P operand has
>>>> some set bits followed by clear bits, i.e. after the != 0 check
>>>> compute ctz_hwi and verify that INTVAL >> ctz == -1?
>>>
>>> I thought of more advanced heuristics but I guess that
>>> any contiguous set of bits with LSB unset might be aligning
>>> if the programmer knows upper bits are zero anyways?  So I fear
>>> the == -1 test would not work reliable?
>>
>> I'd say once a user does & 0x1ff8 or similar, he is doing something weird,
>> and not recursing is the conservatively correct answer (or maybe it isn't?
>> Aren't there cases where we punt if from a binary op we get base terms from
>> both sides and just use one if we get it only from one side?  If so,
>> we might need to have some kind of annotated return, this could have a base
>> term but please don't use it).
> 
> Yes, we might run into the "wrong" one via binary op handling, so
> there isn't really a conservative answer here :/
> 
>> I guess the only non-weird case would be if the target has weird pointer
>> sizes and only has larger or smaller ints, say 24-bit pointer, and 8/16/32
>> integers, so the aligning then could be & 0xfffff8 etc.
> 
> Yeah.  Or the weird ones are exposed by nonzero bits "optimizations"
> of constants.
IIRC all the low order bitmask handling for pointers was primarily to
benefit the Alpha.  I think over time we saw it was helpful for
varargs/stdarg, but that's about it.  I'd be surprised if it's all that
important to dig deeply into addresses of this form.

jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]