Patch RFA: Add option -fcollectible-pointers, use it in ivopts
Richard Biener
richard.guenther@gmail.com
Wed Jan 20 14:15:00 GMT 2016
On Wed, Jan 20, 2016 at 3:02 PM, Ian Lance Taylor <iant@golang.org> wrote:
> On Wed, Jan 20, 2016 at 3:13 AM, Richard Biener
> <richard.guenther@gmail.com> wrote:
>> On Wed, Jan 20, 2016 at 6:48 AM, Ian Lance Taylor <iant@golang.org> wrote:
>>> As discussed at https://gcc.gnu.org/ml/gcc/2016-01/msg00023.html , the
>>> Go frontend needs some way to prevent ivopts from temporarily removing
>>> all pointers into a memory block. This patch adds a new option
>>> -fcollectible-pointers which makes that happen. This is not the best
>>> way to solve the problem, but it seems safe for GCC 6.
>>>
>>> I made the option -fcollectible-pointers intending that any similar
>>> optimizations (or, rather, non-optimizations) can be captured in the
>>> same option. And if we develop a better approach for ivopts, it can
>>> still be covered under this option name.
>>>
>>> Bootstrapped and tested on x86_64-pc-linux-gnu. OK for mainline?
>>
>> + // -fcollectible-pointers means that we have to keep a real pointer
>> + // live, but the ivopts code may replace a real pointer with one
>> + // pointing before or after the memory block that is then adjusted
>> + // into the memory block during the loop.
>> + // FIXME: It would likely be better to actually force the pointer
>> + // live and still use ivopts; for example, it would be enough to
>> + // write the pointer into memory and keep it there until after the
>> + // loop.
>> + if (flag_collectible_pointers && POINTER_TYPE_P (TREE_TYPE (base)))
>> + return;
>>
>> please use C-style comments.
>
> Whoops, sorry, too much Go coding.
>
>> The above is to add_autoinc_candidates
>> which I find weird - we certainly produce out-of-bound pointers even on
>> x86 which isn't auto-inc.
>
> Despite the name, this is used on all systems. That is the function
> where we consider using BASE + STEP * i in a loop.
>
>> So this can't be a complete fix. I guess you
>> are correct in disabling some offsetted address IV candidates but
>> I think there's some other issues regarding to exit test replacement
>> maybe (replace ptr <= ptr2 with ptr != ptr2 or so).
>
> I'll look into that.
>
>> While the docs of the option look fine I find
>>
>> +fcollectible-pointers
>> +Common Report Var(flag_collectible_pointers) Optimization
>> +Ensure that pointers are always collectible by a garbage collector
>>
>> somewhat confusing (we don't collect pointers but pointed-to memory).
>> Maybe "Ensure that derived pointers always point to the original object"?
>> In that light -fcollectible-pointers is a bad option name as well. Maybe
>> -fall-pointers-are-gc-roots or sth like that.
>
> I'm OK with that, or how about -fkeep-gc-roots-live?
Sounds good.
Richard.
> Ian
More information about the Gcc-patches
mailing list