On Mon, Aug 22, 2011 at 6:34 PM, Oleg Smolsky wrote:
> On 2011/8/22 18:09, Oleg Smolsky wrote:
>>
>> Both compilers fully inline the templated function and the emitted code
>> looks very similar. I am puzzled as to why one of these loops is
>> significantly slower than the other. I've attached dis
On 2011/8/22 18:09, Oleg Smolsky wrote:
Both compilers fully inline the templated function and the emitted
code looks very similar. I am puzzled as to why one of these loops is
significantly slower than the other. I've attached disassembled
listings - perhaps someone could have a look please? (
Hey David, these two --param options made no difference to the test.
I've cut the suite down to a single test (attached), which yields the
following results:
./simple_types_constant_folding_os (gcc 41)
test description time operations/s
0 "int8_t constant add" 1.34 sec
On Sun, Aug 21, 2011 at 12:01 PM, Georg-Johann Lay wrote:
>
> Richard Sandiford schrieb:
>>
>> Georg-Johann Lay writes:
>>
>>> Richard Sandiford schrieb:
>>>
I've been working on some patches to make insn_rtx_cost take account
of the cost of SET_DESTs as well as SET_SRCs. But I'm slowl
Dimitrios Apostolou writes:
> My proposal was about doing many small improvements in various parts
> of the compiler, both in CPU and memory utilisation. All in all I
> touched parts from the back-end and the middle-end, to the C frontend,
> but only regarding CPU utilisation. Unfortunately impro
Monday 22nd of August, 2011: pencils down.
Today my GSOC adventure comes to an end. For whoever doesn't know, this
summer I've been trying to make GCC faster. A task that proved much harder
than I initially thought.
My proposal was about doing many small improvements in various parts of
the
On 08/18/11 03:45, Andrew Pinski wrote:
> Forwarding this to the gcc list. Also Adding RTH to the CC since he
> helped Bernd to get the dwarf2 parts working correctly.
> You probably know this already. The c6x-elf target fails to build
> libgcc with the current FSF mainline sources:
>
> gcc/
On Mon, 22 Aug 2011, Toon Moene wrote:
After studying this a bit more, I almost convinced this is due to the upgrade
of Debian Testing I did at 12:15 UTC, Sunday the 21st of August.
Apparently, the install of libc6-2.13-16 does some evil things to the
/usr/include/bits directory ...
Ah, the
On 08/21/2011 08:19 PM, Toon Moene wrote:
See:
http://gcc.gnu.org/ml/gcc-testresults/2011-08/msg02361.html
The configure line is:
../gcc/configure \
--prefix=/tmp/lto \
--enable-languages=c++ \
--with-build-config=bootstrap-lto \
--with-gnu-ld \
--disable-multilib \
--disable-nls \
--with-arc
On Mon, Aug 22, 2011 at 9:08 AM, Joern Rennecke wrote:
> Quoting Richard Guenther :
>
>>> So are you saying that we should remove the recursive nature of the
>>> rtx_cost/targetm.rtx_costs interface, and have the backend handle any
>>> recursion itself? I.e. targetm.rtx_costs only ever sees a com
Quoting Richard Guenther :
So are you saying that we should remove the recursive nature of the
rtx_cost/targetm.rtx_costs interface, and have the backend handle any
recursion itself? I.e. targetm.rtx_costs only ever sees a complete
(but perhaps invalid) instruction pattern? Or would you still
Georg-Johann Lay wrote:
> Ulrich Weigand schrieb:
> > Georg-Johann Lay wrote:
> >
> >>http://gcc.gnu.org/ml/gcc/2011-08/msg00131.html
> >>
> >>Are you going to install that patch? Or maybe you already installed it?
> >
> > No, it isn't approved yet (in fact, it isn't even posted for approval).
>
Paul Edwards wrote:
> if (operands[1] == const0_rtx)
> {
> CC_STATUS_INIT;
> mvs_check_page (0, 6, 8);
> return \"MVC%O0(8,%R0),=XL8'00'\";
> }
> mvs_check_page (0, 6, 8);
> return \"MVC%O0(8,%R0),%1\";
> }"
>[(set_attr "length" "8")]
> )
>
> forces it to use XL8
Richard Sandiford wrote:
> Georg-Johann Lay writes:
IMO a clean approach would be to query the costs of a whole insn (resp.
it's pattern) rather than the cost of an RTX. COSTS_N_INSNS already
indicates that the costs are compared to *insn* costs i.e. cost of the
whole patte
On Mon, Aug 22, 2011 at 10:19 AM, Richard Sandiford
wrote:
> Georg-Johann Lay writes:
IMO a clean approach would be to query the costs of a whole insn (resp.
it's pattern) rather than the cost of an RTX. COSTS_N_INSNS already
indicates that the costs are compared to *insn* costs i.e.
Georg-Johann Lay writes:
>>>IMO a clean approach would be to query the costs of a whole insn (resp.
>>>it's pattern) rather than the cost of an RTX. COSTS_N_INSNS already
>>>indicates that the costs are compared to *insn* costs i.e. cost of the
>>>whole pattern (modulo clobbers).
>>
>> The pr
16 matches
Mail list logo
