Peter Bergner writes:
> Segher Boessenkool writes:
>> So what should we do about this? There are arguments for *both*
>> behaviours, and apparently with LTO we do not know which flags are
>> explicit?
>
> Actually, from my testing, it seems the rs6000_isa_flags_explicit
> flags are set correctl
Segher Boessenkool writes:
> So what should we do about this? There are arguments for *both*
> behaviours, and apparently with LTO we do not know which flags are
> explicit?
Actually, from my testing, it seems the rs6000_isa_flags_explicit
flags are set correctly in LTO!
On 10/15/19 7:45 AM,
On 10/15/19 11:12 AM, Peter Bergner wrote:
> On 10/15/19 10:44 AM, Richard Biener wrote:
>> On October 15, 2019 5:09:52 PM GMT+02:00, Peter Bergner
>> wrote:
>>> If the user explicitly said not to compile a function with a particular
>>> option, how can we justify ignoring that request just becau
On 10/15/19 1:21 PM, Segher Boessenkool wrote:
> On Tue, Oct 15, 2019 at 12:47:02PM -0500, Peter Bergner wrote:
>> I'd say this is user error, telling the compiler it has to inline the callee
>> function, but then using incompatible options on the caller and the callee,
>> so that it cannot. I thi
On Tue, Oct 15, 2019 at 12:47:02PM -0500, Peter Bergner wrote:
> On 10/15/19 4:56 AM, Segher Boessenkool wrote:
> > On Tue, Oct 15, 2019 at 05:15:07PM +0800, Jiufu Guo wrote:
> >> And another issue: Behavior is still inconsistent between "-mno-vsx
> >> -flto" and "-mno-vsx" for user code. Previous
On 10/15/19 4:56 AM, Segher Boessenkool wrote:
> On Tue, Oct 15, 2019 at 05:15:07PM +0800, Jiufu Guo wrote:
>> And another issue: Behavior is still inconsistent between "-mno-vsx
>> -flto" and "-mno-vsx" for user code. Previous patch makes it consistent
>> between "-mvsx -flto" and "-mvsx".
>
>>
On 10/15/19 10:44 AM, Richard Biener wrote:
> On October 15, 2019 5:09:52 PM GMT+02:00, Peter Bergner
> wrote:
>> If the user explicitly said not to compile a function with a particular
>> option, how can we justify ignoring that request just because we're
>> inlining it? We don't do that for th
On October 15, 2019 5:09:52 PM GMT+02:00, Peter Bergner
wrote:
>On 10/15/19 4:32 AM, Richard Biener wrote:
>> I believe this is going to bite you exactly in the case you want the
>> opposite behavior. If you have CUs compiled with defaults and
>> a specialized one with VSX that calls into generi
On 10/15/19 4:32 AM, Richard Biener wrote:
> I believe this is going to bite you exactly in the case you want the
> opposite behavior. If you have CUs compiled with defaults and
> a specialized one with VSX that calls into generic compiled functions
> you _do_ want to allow inlining into the VSX e
Segher Boessenkool writes:
> Hi!
>
> On Tue, Oct 15, 2019 at 05:15:07PM +0800, Jiufu Guo wrote:
>> And another issue: Behavior is still inconsistent between "-mno-vsx
>> -flto" and "-mno-vsx" for user code. Previous patch makes it consistent
>> between "-mvsx -flto" and "-mvsx".
>
>> $GCC_BUILD
On Tue, Oct 15, 2019 at 1:33 PM Segher Boessenkool
wrote:
>
> On Tue, Oct 15, 2019 at 01:19:51PM +0200, Richard Biener wrote:
> > On Tue, Oct 15, 2019 at 12:07 PM Segher Boessenkool
> > wrote:
> > > On Tue, Oct 15, 2019 at 11:32:27AM +0200, Richard Biener wrote:
> > > > > I think we just need to
On Tue, Oct 15, 2019 at 01:19:51PM +0200, Richard Biener wrote:
> On Tue, Oct 15, 2019 at 12:07 PM Segher Boessenkool
> wrote:
> > On Tue, Oct 15, 2019 at 11:32:27AM +0200, Richard Biener wrote:
> > > > I think we just need to fix the bug in the current logic when checking
> > > > whether the call
On Tue, Oct 15, 2019 at 12:07 PM Segher Boessenkool
wrote:
>
> On Tue, Oct 15, 2019 at 11:32:27AM +0200, Richard Biener wrote:
> > > I think we just need to fix the bug in the current logic when checking
> > > whether the caller's ISA flags supports the callee's ISA flags. ...and
> > > for that, I
On Tue, Oct 15, 2019 at 11:32:27AM +0200, Richard Biener wrote:
> > I think we just need to fix the bug in the current logic when checking
> > whether the caller's ISA flags supports the callee's ISA flags. ...and
> > for that, I think we just need to add a test that enforces that the
> > caller's
On Tue, Oct 15, 2019 at 11:52:26AM +0200, Andreas Schwab wrote:
> On Okt 15 2019, Segher Boessenkool wrote:
>
> > Please use
> > /* { dg-final { scan-assembler "\mbl vadd_no_vsx\M" } } */
>
> ITYM
>
> /* { dg-final { scan-assembler {\mbl vadd_no_vsx\M} } } */
Ha yes, thanks :-) That's t
Hi!
On Tue, Oct 15, 2019 at 05:15:07PM +0800, Jiufu Guo wrote:
> And another issue: Behavior is still inconsistent between "-mno-vsx
> -flto" and "-mno-vsx" for user code. Previous patch makes it consistent
> between "-mvsx -flto" and "-mvsx".
> $GCC_BUILD/gcc/xgcc -B$GCC_BUILD/gcc novsx.c -O2
On Okt 15 2019, Segher Boessenkool wrote:
> Please use
> /* { dg-final { scan-assembler "\mbl vadd_no_vsx\M" } } */
ITYM
/* { dg-final { scan-assembler {\mbl vadd_no_vsx\M} } } */
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748
Segher Boessenkool wrote:
> Hi!
>
> On Mon, Oct 14, 2019 at 07:18:11PM -0500, Peter Bergner wrote:
>> On 10/14/19 2:57 PM, Segher Boessenkool wrote:
>>> On Mon, Oct 14, 2019 at 06:35:06PM +0200, Richard Biener wrote:
The general case should be that if the caller ISA supports the callee one
On Tue, Oct 15, 2019 at 2:18 AM Peter Bergner wrote:
>
> On 10/14/19 2:57 PM, Segher Boessenkool wrote:
> > On Mon, Oct 14, 2019 at 06:35:06PM +0200, Richard Biener wrote:
> >> The general case should be that if the caller ISA supports the callee one
> >> then inlining is OK. If this is not wanted
Hi!
On Mon, Oct 14, 2019 at 07:18:11PM -0500, Peter Bergner wrote:
> On 10/14/19 2:57 PM, Segher Boessenkool wrote:
> > On Mon, Oct 14, 2019 at 06:35:06PM +0200, Richard Biener wrote:
> >> The general case should be that if the caller ISA supports the callee one
> >> then inlining is OK. If this i
Peter Bergner writes:
>
> I think we just need to fix the bug in the current logic when checking
> whether the caller's ISA flags supports the callee's ISA flags. ...and
> for that, I think we just need to add a test that enforces that the
> caller's ISA flags match exactly the callee's flags
Jiufu Guo writes:
> Thanks for all your reviews and comments, very helpful!
>
> Peter Bergner writes:
>
>> I think we just need to fix the bug in the current logic when checking
>> whether the caller's ISA flags supports the callee's ISA flags. ...and
>> for that, I think we just need to add a t
Thanks for all your reviews and comments, very helpful!
Peter Bergner writes:
> I think we just need to fix the bug in the current logic when checking
> whether the caller's ISA flags supports the callee's ISA flags. ...and
> for that, I think we just need to add a test that enforces that the
On 10/14/19 2:57 PM, Segher Boessenkool wrote:
> On Mon, Oct 14, 2019 at 06:35:06PM +0200, Richard Biener wrote:
>> The general case should be that if the caller ISA supports the callee one
>> then inlining is OK. If this is not wanted in some cases then there are
>> options like using a noinline a
On Mon, Oct 14, 2019 at 06:35:06PM +0200, Richard Biener wrote:
> The general case should be that if the caller ISA supports the callee one
> then inlining is OK. If this is not wanted in some cases then there are
> options like using a noinline attribute.
I agree, and that is what we already d
On Mon, Oct 14, 2019 at 10:31:58AM -0500, Peter Bergner wrote:
> I agree with your other comment that we should be looking at explicit option
> usage versus default options. However, the way we now implement default CPU,
> the gcc driver always passes a -mcpu= option to cc1 no matter if the user
>
On October 14, 2019 5:31:58 PM GMT+02:00, Peter Bergner
wrote:
>On 10/12/19 3:46 AM, Segher Boessenkool wrote:
>> Two spaces after a period. How about something like
>>
>> /* Callee's options should be a subset of the caller's. Also,
>a function
>> without VSX enabled should not be
On 10/12/19 3:46 AM, Segher Boessenkool wrote:
> Two spaces after a period. How about something like
>
> /* Callee's options should be a subset of the caller's. Also, a
> function
>without VSX enabled should not be inlined into one with VSX enabled,
>because it may be impo
Hi!
On Sat, Oct 12, 2019 at 11:22:15AM +0800, Jiufu Guo wrote:
> As expected in the PR, when a function is marked with no-vsx, we would
> assume user has good reason to disable VSX code generation for the function.
> To avoid VSX code generation, this function should not be inlined into VSX
> fu
Hi,
As expected in the PR, when a function is marked with no-vsx, we would
assume user has good reason to disable VSX code generation for the function.
To avoid VSX code generation, this function should not be inlined into VSX
function.
In previous implementation, function with non-vsx is trea
30 matches
Mail list logo
