On 11/10/2010 12:47 AM, Joern Rennecke wrote:
I remember that it has been there even before the GNU GCC project started
using cvs. Fortunately, we still have the translated history from RCS
going backeven further... but the earliest mention of find_split_point
in combine.c is shown as having
Hi,
I was wondering if gcc has software pipelining.
I saw options -fsel-sched-pipelining -fselective-scheduling
-fselective-scheduling2 but I don't see any pipelining happening
(tried with ia64).
Is there a gcc VLIW port in which I can see it working?
For an example function like
int nor(char* _
On 11/10/2010 11:58 AM, Georg Lay wrote:
In the old 3.4.x (private port) I introduced a target hook in combine,
just prior to where recog_for_combine gets called. The hook did some
canonicalization of rtx and thereby considerably reduced the number of
patterns that would have been necessary witho
Michael Meissner schrieb:
> In particular, go to pages 5-7 of my tutorial (chapter 6) where I talk about
> scratch registers and allocating a new pseudo in split1 which is now always
> run.
Ah great! That's the missing link. The pseudo hatches in split1 from
scratch.
This makes combine even more
Hi,
On 10.11.2010 12:32, roy rosen wrote:
Hi,
I was wondering if gcc has software pipelining.
I saw options -fsel-sched-pipelining -fselective-scheduling
-fselective-scheduling2 but I don't see any pipelining happening
(tried with ia64).
Is there a gcc VLIW port in which I can see it working?
Y
On 09/11/10 22:54, Michael Meissner wrote:
The split pass would then break this back into three insns:
(insn ... (set (reg:SF ACC_REGISTER)
(mult:SF (reg:SF 124)
(reg:SF 125
(insn ... (set (reg:SF ACC_REGISTER)
Would it be possible to use the named address space syntax to implement
reverse-endian data? Conversion between little-endian and big-endian
data structures is something that turns up regularly in embedded
systems, where you might well be using two different architectures with
different endian
Thank you, that worked out eventually.
However, now I have another problem. I have 2 instructions in the ISA:
'where' and 'endwhere' which modify the behavior of the instructions put
in between them. I made a macro with inline assembly for each of them. The
problem is that since `endwhere` doesn't
Two merges, actually. The first one at r165633, the second at
r166509.
Bootstrapped and tested on x86_64.
Diego.
David,
for s390 we would also be interested in a solution like that. s390 is big
endian and
endianess conflicts often come in the way when porting an application from
'other'
platforms. Linus Torvalds already in 2001 made a quite similiar suggestions
using a type
attribute:
http://gcc.gnu.org
"Radu Hobincu" writes:
> However, now I have another problem. I have 2 instructions in the ISA:
> 'where' and 'endwhere' which modify the behavior of the instructions put
> in between them. I made a macro with inline assembly for each of them. The
> problem is that since `endwhere` doesn't have a
Paolo Bonzini schrieb:
> On 11/10/2010 11:58 AM, Georg Lay wrote:
>> In the old 3.4.x (private port) I introduced a target hook in combine,
>> just prior to where recog_for_combine gets called. The hook did some
>> canonicalization of rtx and thereby considerably reduced the number of
>> patterns t
> "Radu Hobincu" writes:
>
>> However, now I have another problem. I have 2 instructions in the ISA:
>> 'where' and 'endwhere' which modify the behavior of the instructions put
>> in between them. I made a macro with inline assembly for each of them.
>> The
>> problem is that since `endwhere` does
I have 16 vectorial registers in the machine R16-R31 which all have 128
cells of 16 bits each. These support ALU operations and load/stores just
as normal registers, but in one clock. So an
add R16 R17 R18
will add the whole R17 array with R18 (corresponding cells) and place the
result in R1
On Nov 10, 2010, at 4:00 AM, David Brown wrote:
> Would it be possible to use the named address space syntax to implement
> reverse-endian data? Conversion between little-endian and big-endian data
> structures is something that turns up regularly in embedded systems, where
> you might well b
C++ lets you define explicit-order integer types and hide all the conversions.
I used that a couple of jobs ago, back around 1996 or so -- worked nicely, and
should work even better now that C++ is more mature.
paul
On Nov 10, 2010, at 7:00 AM, David Brown wrote:
> Would it be possibl
"Radu Hobincu" writes:
> I have 16 vectorial registers in the machine R16-R31 which all have 128
> cells of 16 bits each. These support ALU operations and load/stores just
> as normal registers, but in one clock. So an
>
> add R16 R17 R18
>
> will add the whole R17 array with R18 (corresponding c
On 10/11/10 17:55, Chris Lattner wrote:
On Nov 10, 2010, at 4:00 AM, David Brown wrote:
Would it be possible to use the named address space syntax to
implement reverse-endian data? Conversion between little-endian
and big-endian data structures is something that turns up regularly
in embedded
On 10/11/10 18:05, Paul Koning wrote:
C++ lets you define explicit-order integer types and hide all the
conversions. I used that a couple of jobs ago, back around 1996 or
so -- worked nicely, and should work even better now that C++ is more
mature.
Yes, a lot of such things can be done with C
CALL FOR PAPERS
3rd Workshop on
GCC Research Opportunities
(GROW 2011)
http://grow2
20 matches
Mail list logo
