Re: [PATCH] Steam out non-explicit -fno-tree-loop-distribute-patterns for LTO options

[Kito Cheng <kito dot cheng at gmail dot com>]

Hi Richard:

I think preserve -fno-builtin is better than
-fno-tree-loop-distribute-patterns too,

However if we preserve -fno-builtin, the coming problem is should we
preserve all -fbuiltin-* and do the check logic[1] in common code in
gcc?

btw, in our internal gcc 4.9.x tree is move -fno-builtin to common
group (CL_COMMON) (preserve in lto since it's in CL_COMMON)  and check
it in tree-loop-distribution.c for temporary workaround .

[1] gcc/c-family/c-common.c:disable_builtin_function

On Thu, Aug 28, 2014 at 4:45 PM, Richard Biener
<richard.guenther@gmail.com> wrote:
> On Wed, Aug 27, 2014 at 4:42 PM, Kito Cheng <kito.cheng@gmail.com> wrote:
>> Hi all:
>>
>> This patch basically is extension for r210100[1], stream out
>> non-explicit -fno-tree-loop-distribute-patterns since compile with
>> `-flto -O3 -fno-builtin` still may gen builtin function call during
>> LTO phase.
>>
>> LTO bootstrapped and tested on x86_64-unknown-linux-gnu.
>
> Hmm, but that will for two units, one compiled with -O2 and one
> compiled with -O3, produce -O3 -fno-tree-loop-distribute-patterns.
> The previous patch restricted this to -ffreestanding / -fno-builtin.
>
> I think it makes more sense to preserve -fno-builtin, that is,
> add 'LTO' to the list of FEs supporting 'fbuiltin' (the non-joined version)
> and stream '-fno-builtin' if set, doing similar option post-processing
> in the LTO frontend as I added to the C family frontends.
>
> Richard.
>
>> 2014-09-27  Kito Cheng  <kito@0xlab.org>
>>
>>     * lto-opts.c (lto_write_options): Output non-explicit
>>     -fno-tree-loop-distribute-patterns.
>>     * lto-wrapper.c (merge_and_complain): Merge
>>     -fno-tree-loop-distribute-patterns conservatively.
>>     (run_gcc): Pass through -fno-tree-loop-distribute-patterns.
>>
>>
>> [1] https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=210100