On Thu, Jan 26, 2017 at 01:57:02PM +0100, Bernd Schmidt wrote:
> On 01/25/2017 08:46 PM, Segher Boessenkool wrote:
> >
> >It turns out my patch (see the PR) causes (or at least triggers)
> >miscompilations on tilegx. I will drop it for now.
>
> Curious, it looked very reasonable. What's needed to
On 01/25/2017 08:46 PM, Segher Boessenkool wrote:
It turns out my patch (see the PR) causes (or at least triggers)
miscompilations on tilegx. I will drop it for now.
Curious, it looked very reasonable. What's needed to reproduce this?
Bernd
On Fri, Jan 20, 2017 at 01:24:15PM -0600, Segher Boessenkool wrote:
> On Fri, Jan 20, 2017 at 01:33:59PM +0100, Bernd Schmidt wrote:
> > So, when looking for situations where we have only one condition, we can
> > try to undo the conversion of a plain REG into a condition, on the
> > grounds that
On 25/01/17 15:20, Christophe Lyon wrote:
On 25 January 2017 at 15:55, Bernd Schmidt wrote:
On 01/25/2017 10:18 AM, Kyrill Tkachov wrote:
The test is supposed to test the generation of the vsel instruction.
I believe adding an -mcpu=cortex-a57 to the testcases would be best, as
VSEL isn't act
On 25 January 2017 at 15:55, Bernd Schmidt wrote:
> On 01/25/2017 10:18 AM, Kyrill Tkachov wrote:
>>
>> The test is supposed to test the generation of the vsel instruction.
>> I believe adding an -mcpu=cortex-a57 to the testcases would be best, as
>> VSEL isn't actually available on Cortex-A5, it'
On 01/25/2017 10:18 AM, Kyrill Tkachov wrote:
The test is supposed to test the generation of the vsel instruction.
I believe adding an -mcpu=cortex-a57 to the testcases would be best, as
VSEL isn't actually available on Cortex-A5, it's just enabled by the
-mfpu=fp-armv8 option.
A more realistic c
On 25/01/17 09:29, Christophe Lyon wrote:
> On 25 January 2017 at 10:18, Kyrill Tkachov
> wrote:
>>
>> On 25/01/17 08:53, Christophe Lyon wrote:
>>>
>>> On 24 January 2017 at 18:15, Bernd Schmidt wrote:
On 01/24/2017 06:03 PM, Christophe Lyon wrote:
>
> Ha... the regression occ
On 25 January 2017 at 10:18, Kyrill Tkachov wrote:
>
> On 25/01/17 08:53, Christophe Lyon wrote:
>>
>> On 24 January 2017 at 18:15, Bernd Schmidt wrote:
>>>
>>> On 01/24/2017 06:03 PM, Christophe Lyon wrote:
Ha... the regression occurred between r 244818 and r 244816,
and I read r
On 25/01/17 08:53, Christophe Lyon wrote:
On 24 January 2017 at 18:15, Bernd Schmidt wrote:
On 01/24/2017 06:03 PM, Christophe Lyon wrote:
Ha... the regression occurred between r 244818 and r 244816,
and I read r 244816 ChangeLog too quickly and did not notice
it was modifying ifcvt.c in add
On 24 January 2017 at 18:15, Bernd Schmidt wrote:
> On 01/24/2017 06:03 PM, Christophe Lyon wrote:
>>
>> Ha... the regression occurred between r 244818 and r 244816,
>> and I read r 244816 ChangeLog too quickly and did not notice
>> it was modifying ifcvt.c in addition to x86-only files.
>>
>> So
On 01/24/2017 06:03 PM, Christophe Lyon wrote:
Ha... the regression occurred between r 244818 and r 244816,
and I read r 244816 ChangeLog too quickly and did not notice
it was modifying ifcvt.c in addition to x86-only files.
So it's likely that it's your other patch for pr78634
that caused the
On 24 January 2017 at 17:55, Bernd Schmidt wrote:
> On 01/24/2017 05:50 PM, Kyrill Tkachov wrote:
>>
>>
>> Actually trying it out with an explicit -mcpu=cortex-a5 (so -O2 -S
>> -mfpu=fp-armv8 -mcpu=cortex-a57 -mfloat-abi=hard) I get
>> the test failing before and after the patch. The code generate
On 01/24/2017 05:50 PM, Kyrill Tkachov wrote:
Actually trying it out with an explicit -mcpu=cortex-a5 (so -O2 -S
-mfpu=fp-armv8 -mcpu=cortex-a57 -mfloat-abi=hard) I get
the test failing before and after the patch. The code generated is
vcmp.f64d0, d1
vmrsAPSR_nzcv, FP
On 24/01/17 16:36, Bernd Schmidt wrote:
On 01/24/2017 05:30 PM, Kyrill Tkachov wrote:
The -mfpu is overridden in the testcase to add the ARMv8 instructions.
So to reproduce the compilation in that testcase you'd want
-mfpu=fp-armv8 or
something equivalent rather than vfpv3-d16-fp16.
Exact st
On 01/24/2017 05:30 PM, Kyrill Tkachov wrote:
The -mfpu is overridden in the testcase to add the ARMv8 instructions.
So to reproduce the compilation in that testcase you'd want
-mfpu=fp-armv8 or
something equivalent rather than vfpv3-d16-fp16.
Exact steps please. No one who's not well-versed i
On 24/01/17 16:28, Christophe Lyon wrote:
On 24 January 2017 at 17:02, Kyrill Tkachov wrote:
On 24/01/17 15:21, Segher Boessenkool wrote:
On Tue, Jan 24, 2017 at 01:40:46PM +0100, Bernd Schmidt wrote:
On 01/24/2017 09:38 AM, Christophe Lyon wrote:
It seems that Bernd's patch causes regressi
On 24 January 2017 at 17:02, Kyrill Tkachov wrote:
>
> On 24/01/17 15:21, Segher Boessenkool wrote:
>>
>> On Tue, Jan 24, 2017 at 01:40:46PM +0100, Bernd Schmidt wrote:
>>>
>>> On 01/24/2017 09:38 AM, Christophe Lyon wrote:
It seems that Bernd's patch causes regressions on arm-linux-gnue
On 24/01/17 15:21, Segher Boessenkool wrote:
On Tue, Jan 24, 2017 at 01:40:46PM +0100, Bernd Schmidt wrote:
On 01/24/2017 09:38 AM, Christophe Lyon wrote:
It seems that Bernd's patch causes regressions on arm-linux-gnueabihf
--with-cpu=cortex-a5 --with-fpu=vfpv3-d16-fp16:
gcc.target/arm/vse
On Tue, Jan 24, 2017 at 01:40:46PM +0100, Bernd Schmidt wrote:
> On 01/24/2017 09:38 AM, Christophe Lyon wrote:
> >It seems that Bernd's patch causes regressions on arm-linux-gnueabihf
> >--with-cpu=cortex-a5 --with-fpu=vfpv3-d16-fp16:
> >
> > gcc.target/arm/vselvcdf.c scan-assembler-times vselvs.
On 01/24/2017 09:38 AM, Christophe Lyon wrote:
It seems that Bernd's patch causes regressions on arm-linux-gnueabihf
--with-cpu=cortex-a5 --with-fpu=vfpv3-d16-fp16:
gcc.target/arm/vselvcdf.c scan-assembler-times vselvs.f64\td[0-9]+ 1
gcc.target/arm/vselvcsf.c scan-assembler-times vselvs.f32\
On 20 January 2017 at 20:24, Segher Boessenkool
wrote:
> Hi Bernd,
>
> On Fri, Jan 20, 2017 at 01:33:59PM +0100, Bernd Schmidt wrote:
>> So, when looking for situations where we have only one condition, we can
>> try to undo the conversion of a plain REG into a condition, on the
>> grounds that th
Hi Bernd,
On Fri, Jan 20, 2017 at 01:33:59PM +0100, Bernd Schmidt wrote:
> So, when looking for situations where we have only one condition, we can
> try to undo the conversion of a plain REG into a condition, on the
> grounds that this is probably less helpful.
>
> This seems to cure the testc
The PR is about infinite recursion in combine_simplify_rtx, because
if_then_else_cond does strange things to an expression, and we end up
simplifying something to itself. The patch below tries to address this
by improving that function a little. As stated in the PR, the situation
is that we hav
23 matches
Mail list logo
