Dear SC members,
I used to maintain the picochip port of GCC, but I have not been
active on the picochip port over the last 8 months. This is unlikely
to change in the future, so I would like my name to be removed from
the maintainers list as picochip maintainer. I am still actively
working on GCC,
Hi Ian,
Thanks for your help.
I switched to mainline and the vector extract works a treat. When i
tried vector set, it was still generating suboptimal code. Is this bit
of code still work in progress?
Cheers
Hari
On 04/11/10 19:23, Ian Lance Taylor wrote:
Hariharan Sandanagobalane writes
Hello all,
Is it possible to use rtl vector patterns like vec_extractm, vec_setm
from C code? It looks like C subscipting for vector variables was
allowed at some point and then removed. So, can these rtl patterns only
be used from languages other than C?
Of course, i can use these in target
Jeff Law wrote:
On 05/24/10 05:46, Hariharan wrote:
Hello all,
I found something a little odd with delay slot scheduling. If i had
the following bit of code (Note that "get" builtin functions in
picochip stand for port communication)
int mytest ()
{
int a[5];
int i;
for (i = 0; i < 5; i
instruction that should be
moved but not?
Cheers,
Bingfeng
-Original Message-
From: Hariharan Sandanagobalane [mailto:harihar...@picochip.com]
Sent: 14 May 2010 12:26
To: Bingfeng Mei
Cc: gcc@gcc.gnu.org
Subject: Re: Machine description question
Hi Bengfeng,
Changing my instruction patterns
ll porivate and not in mainline.
Cheers,
Bingfeng
-Original Message-
From: Hariharan Sandanagobalane [mailto:harihar...@picochip.com]
Sent: 13 May 2010 10:17
To: Bingfeng Mei
Cc: gcc@gcc.gnu.org
Subject: Re: Machine description question
The patterns for PUT/GET were
; Scalar Pu
that i was using for GET, which was inside a loop, was being
hoisted out of the loop by the loop optimizer. I guess i should have
seen this coming, since unspec is just "machine-specific" operation and
the optimizer probably rightly assumes that multiple execution of this
Thanks for your help BingFeng.
I gave this a go and ended up with worse code (and worse memory usage)
than before. I started with this experiment because of the compilers
"All virtual registers are assumed to be used and clobbered by
unspec_volatile" rule. The get/put instructions read/write t
e-use
to build optimized code using the profile data.
Seongbae
On Thu, Jan 8, 2009 at 6:30 AM, Hariharan Sandanagobalane
wrote:
Hi Seongbae,
I was doing some work on profiling for picochip, when i noticed what looks
to me like a bug. It looks to me that using fbranch-probabilities on the
comman
Yes, if i change the structure to bring the 3 1-bit members forward, to
avoid padding, the testcase does pass.
Thanks to both of you for your help.
Cheers
Hari
Jakub Jelinek wrote:
On Tue, Mar 10, 2009 at 01:44:11PM +, Hariharan Sandanagobalane wrote:
Since r144598, pr39339.c has been
Hi,
Since r144598, pr39339.c has been failing on picochip. On investigation,
it looks to me that the testcase is illegal.
Relevant source code:
struct C
{
unsigned int c;
struct D
{
unsigned int columns : 4;
unsigned int fore : 9;
unsigned int back : 9;
unsigned int fragme
Hi Seongbae,
I was doing some work on profiling for picochip, when i noticed what
looks to me like a bug. It looks to me that using fbranch-probabilities
on the commandline (after a round of profile-generate or profile-arcs)
would just not work on any target. Reason..
Coverage.c:1011
if (f
Hello,
I see quite a few instances when i get the following RTL. A conditional
branch, followed by a BASIC_BLOCK note, followed by a non-TImode
instruction. Theoretically, i should be allowed to package the non-TI
instruction along with the conditional branch, but doing so seems to be
produce
Hi thomas,
Thanks for your reply. A couple of questions below.
Thomas Sailer wrote:
Has anyone faced a similar problem before? Are there targets for which
both VLIW and DBR are enabled? Perhaps ia64?
I did something similar a few months ago.
What was your target? Is the target code available
Hi,
I am trying to enable delayed branch scheduling on our port of Gcc for
picochip (16-bit VLIW DSP). I understand that delayed-branch is run as a
seperate pass after the DFA scheduling is done. We basically depend on
the TImode set on the cycle-start instructions to decide what
instructions
Seongbae Park (???, ???) wrote:
On 9/27/07, Hariharan Sandanagobalane <[EMAIL PROTECTED]> wrote:
Hello,
I am implementing support for PBO on picochip port of GCC (not yet
submitted to mainline).
I see that GCC generates 2 files, xx.gcno and xx.gcda, containing the
profile informatio
Hello,
I am implementing support for PBO on picochip port of GCC (not yet
submitted to mainline).
I see that GCC generates 2 files, xx.gcno and xx.gcda, containing the
profile information, the former containing the flow graph
information(compile-time) and later containing the edge profile
in
Ian Lance Taylor wrote:
Hariharan Sandanagobalane <[EMAIL PROTECTED]> writes:
I looked at an inefficient code sequence for a simple program using
GCC's picochip port (not yet submitted to mainline).
Are you working with mainline sources?
I was not. I tried the same with gcc
Hello,
I looked at an inefficient code sequence for a simple program using
GCC's picochip port (not yet submitted to mainline). Basically, a
program like
long carray[10];
void fn (long c, int i)
{
carray[i] = c;
}
produces good assembly code. But, if i were to do
struct complex16
{
int re,i
19 matches
Mail list logo
