Andreas Krebbel writes:
> On 05/17/2015 11:12 PM, Richard Sandiford wrote:
>> Andreas Krebbel writes:
>>> Hi Richard,
>>>
>>> I see regressions with the current IBM z13 vector patchset which appear to
>>> be related to the new
>>> genrecog.
>>>
>>> The following two insn definitions only differ
On 05/17/2015 11:12 PM, Richard Sandiford wrote:
> Andreas Krebbel writes:
>> Hi Richard,
>>
>> I see regressions with the current IBM z13 vector patchset which appear to
>> be related to the new
>> genrecog.
>>
>> The following two insn definitions only differ in the mode and predicate of
>> th
On 05/21/2015 09:12 AM, Thomas Schwinge wrote:
OK to commit?
gcc/
* config/nvptx/nvptx.md (allocate_stack): Rename to...
(allocate_stack_): ... this, and add :P on both
match_operand and unspec.
(allocate_stack): New expander.
If you really want to. It
Hi!
On Thu, 7 May 2015 11:14:37 +0200, Jakub Jelinek wrote:
> On Thu, May 07, 2015 at 10:59:01AM +0200, Thomas Schwinge wrote:
> > build/genrecog [...]/source-gcc/gcc/common.md
> > [...]/source-gcc/gcc/config/nvptx/nvptx.md \
> >insn-conditions.md > tmp-recog.c
> > -[...
Andreas Krebbel writes:
> Hi Richard,
>
> I see regressions with the current IBM z13 vector patchset which appear to be
> related to the new
> genrecog.
>
> The following two insn definitions only differ in the mode and predicate of
> the shift count operand.
>
> (define_insn "lshr3"
> [(set (
Hi Richard,
I see regressions with the current IBM z13 vector patchset which appear to be
related to the new
genrecog.
The following two insn definitions only differ in the mode and predicate of the
shift count operand.
(define_insn "lshr3"
[(set (match_operand:VI 0 "register_op
Hi!
On Mon, 27 Apr 2015 11:20:30 +0100, Richard Sandiford
wrote:
> This patch [...] by replacing most of genrecog [...]
OK to commit?
Is it a bug that I'm seeing these warnings only in the stage 1 build with
the bootstrap GCC 4.6 compiler, but not anymore later on? (I have not
verified the C+
On Thu, May 07, 2015 at 10:59:01AM +0200, Thomas Schwinge wrote:
> build/genrecog [...]/source-gcc/gcc/common.md
> [...]/source-gcc/gcc/config/nvptx/nvptx.md \
>insn-conditions.md > tmp-recog.c
> -[...]/source-gcc/gcc/config/nvptx/nvptx.md:1206: warning: operand 0
> missi
Hi!
On Mon, 27 Apr 2015 11:20:30 +0100, Richard Sandiford
wrote:
> I think it's been the case for a while that parallel builds of GCC tend
> to serialise around the compilation of insn-recog.c, especially with
> higher --enable-checking settings. This patch tries to speed that
> up by replacing
On 05/01/2015 06:41 AM, Richard Sandiford wrote:
Richard Sandiford writes:
Richard Biener writes:
On Thu, Apr 30, 2015 at 2:08 PM, Andreas Schwab wrote:
Richard Sandiford writes:
Andreas Schwab writes:
Richard Sandiford writes:
/* Represents a test and the action that should be take
Richard Sandiford writes:
> Richard Biener writes:
>> On Thu, Apr 30, 2015 at 2:08 PM, Andreas Schwab
>> wrote:
>>> Richard Sandiford writes:
>>>
Andreas Schwab writes:
> Richard Sandiford writes:
>
>> /* Represents a test and the action that should be taken on the result.
>
Richard Biener writes:
> On Thu, Apr 30, 2015 at 2:08 PM, Andreas Schwab wrote:
>> Richard Sandiford writes:
>>
>>> Andreas Schwab writes:
Richard Sandiford writes:
> /* Represents a test and the action that should be taken on the result.
>If a transition exists for the t
On Thu, Apr 30, 2015 at 2:08 PM, Andreas Schwab wrote:
> Richard Sandiford writes:
>
>> Andreas Schwab writes:
>>> Richard Sandiford writes:
>>>
/* Represents a test and the action that should be taken on the result.
If a transition exists for the test outcome, the machine switches
Richard Sandiford writes:
> Andreas Schwab writes:
>> Richard Sandiford writes:
>>
>>> /* Represents a test and the action that should be taken on the result.
>>>If a transition exists for the test outcome, the machine switches
>>>to the transition's target state. If no suitable transi
Bin.Cheng writes:
> Hi Richard,
> I noticed that this patch caused ICE for gcc.target/arm/mmx-2.c on
> arm-none-linux-gnueabi. Could you please have a look at it?
>
> The log message is as below,
> /projects/.../src/gcc/gcc/testsuite/gcc.target/arm/mmx-2.c: In function 'foo':
> /projects/.../src/
> The generated code. genrecog.c itself isn't bad. :-)
Nice work then.
> OK. I'd left the head comment alone because it just described the
> interface, which hasn't changed. But I suppose past lack of commentary
> doesn't justify future lack of commentary. Here's what I added:
> [...]
> BTW,
Andreas Schwab writes:
> Richard Sandiford writes:
>
>> /* Represents a test and the action that should be taken on the result.
>>If a transition exists for the test outcome, the machine switches
>>to the transition's target state. If no suitable transition exists,
>>the machine eith
Richard Sandiford writes:
> /* Represents a test and the action that should be taken on the result.
>If a transition exists for the test outcome, the machine switches
>to the transition's target state. If no suitable transition exists,
>the machine either falls through to the next de
On Mon, Apr 27, 2015 at 6:20 PM, Richard Sandiford
wrote:
> I think it's been the case for a while that parallel builds of GCC tend
> to serialise around the compilation of insn-recog.c, especially with
> higher --enable-checking settings. This patch tries to speed that
> up by replacing most of
Jeff Law writes:
> On 04/27/2015 04:20 AM, Richard Sandiford wrote:
>> Tested on x86_64-linux-gnu, aarch64-linux-gnu and arm-none-eabi.
>> Also tested by building the testsuite for each of the targets above
>> and making sure there were no assembly differences. Made sure that no
>> objects in spe
Eric Botcazou writes:
>> Also, the code is all goto-based, which makes it rather hard to step
>> through.
>
> Do you mean the code in genrecog.c or the generated code in insn-recog.c?
The generated code. genrecog.c itself isn't bad. :-)
>> PS. I've attached the new genrecog.c since the diff ver
> I think it's been the case for a while that parallel builds of GCC tend
> to serialise around the compilation of insn-recog.c, especially with
> higher --enable-checking settings. This patch tries to speed that
> up by replacing most of genrecog with a new algorithm.
I can confirm this, especia
On 04/27/2015 04:20 AM, Richard Sandiford wrote:
I think it's been the case for a while that parallel builds of GCC tend
to serialise around the compilation of insn-recog.c, especially with
higher --enable-checking settings. This patch tries to speed that
up by replacing most of genrecog with a
I think it's been the case for a while that parallel builds of GCC tend
to serialise around the compilation of insn-recog.c, especially with
higher --enable-checking settings. This patch tries to speed that
up by replacing most of genrecog with a new algorithm.
I think the main problems with the
24 matches
Mail list logo
