Jean Christophe Beyler writes:
> typedef struct sTestUnsignedChar {
> uint64_t a:1;
> }STestUnsignedChar;
>
> uint64_t getU (STestUnsignedChar a)
> {
> return a.a;
> }
>
>
> I get this in the DCE pass :
> (insn 6 3 7 2 bitfield2.c:8 (set (subreg:DI (reg:QI 75) 0)
> (zero_extract:DI
Mat Hostetter writes:
> Adam Nemet writes:
>
> > Ian Lance Taylor writes:
> > > Mat Hostetter writes:
> > >
> > >> Since the high bits are already zero, that would be less efficient on
> > >> most platforms, so guarding it wit
Ian Lance Taylor writes:
> Mat Hostetter writes:
>
>> Since the high bits are already zero, that would be less efficient on
>> most platforms, so guarding it with something like this would probably
>> be smarter:
>>
>> if (targetm.mode_rep_extended (mode, GET_MODE(x)) == SIGN_EXTEND)
>> ret
fanqifei writes:
> 2010/1/18 Adam Nemet :
> > Sorry for jumping in late. See make_file_assigment in combine.c.
> >
> > The problem usually is that:
> >
> > (set A (ior (and B C1) OTHER))
> >
> > can only be turned into a bit-insertion if A and B ha
fanqifei writes:
> Paolo Bonzini said that insv instruction might be synthesized
> later by combine. But combine only works on at most 3 instructions and
> insv is not generated in such case.
> So exactly when will the insv pattern be recognized and how does
> the coding style affect it?
Paul Brook writes:
>> Nothing you've said changes the fact that there are a class of users
>> for whom that information is vital and we ought to spend some time
>> thinking about how to provide the information in a form they can
>> digest. GCC dumps as they exist today are largely useless for a
Diego Novillo writes:
> If anyone has free cycles I would appreciate results from other
> ELF-capable targets.
The branch on mipsisa64-elf looks good (no regressions with languages
c,c++,objc):
http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg02717.html
baseline:
http://gcc.gnu.org/ml/gcc-
Richard Henderson writes:
> On 09/01/2009 12:48 PM, Adam Nemet wrote:
> > I see. So I guess you're saying that there is little chance to optimize the
> > loop I had in my previous email ;(.
>
> Not at the rtl level. Gimple-level loop splitting should do it though.
&
Richard Henderson writes:
> On 08/28/2009 12:38 AM, Adam Nemet wrote:
> > ... To assist the linker we need to annotate the indirect call
> > with the function symbol.
> >
> > Since the call is expanded early...
>
> Having experimented with this on Alpha a few y
On MIPS, PIC calls are indirect calls that need to be dispatched via an ABI
mandated register. At expansion time we load the symbol into a pseudo then
expand the call. There is a linker optimization that can turn these indirect
calls into direct calls under some circumstances. This can improve b
Charles J. Tabony writes:
> Filed as PR 41171.
Thanks.
> Is this actually a performance regression on MIPS? I suspect either
> sequence would be the same performance on most machines.
Yes it is: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41171#c1
Adam
"Charles J. Tabony" writes:
> I see the same difference between GCC 4.3.2 and 4.4.0 when compiling
> for PowerPC, MIPS, ARM, and FR-V.
I can confirm this with mainline on MIPS/Octeon. Can you please file a
bug.
Adam
Markus L writes:
> I run into an assert in convert_memory_address not beeing able to
> convert the address rtx (beeing HImode) into to Pmode (i.e. QImode). A
> few frames up the I can dump the tree node and it looks like the
> address calculations are done in HImode. Why is the address beeing
> ca
Jean Christophe Beyler writes:
> As we can see, all three are using the symbol_ref data before adding
> their offset. But after cse, we get this:
>
> (insn 5 2 6 2 ex1b.c:8 (set (reg/f:DI 74)
> (const:DI (plus:DI (symbol_ref:DI ("data") )
> (const_int 8 [0x8] 71 {movdi_
Jean Christophe Beyler writes:
> uint64_t foo (void)
> {
> return data[0] + data[1] + data[2];
> }
>
> And this generates :
>
> la r9,data
> la r7,data+8
> ldd r6,0(r7)
> ldd r8,0(r9)
> ldd r7,16(r9)
>
> I'm trying to see if there is a problem with my rtx costs function
>
Ian Lance Taylor writes:
> I would like to encourage people to try using --enable-build-with-cxx in
> other configuration--other bootstraps, cross-compilers--to see how well
> it works. Please let me know if you run into problems that you don't
> know how, or don't have time, to fix.
MIPS bootst
Ian Lance Taylor writes:
> I would like to encourage people to try using --enable-build-with-cxx in
> other configuration--other bootstraps, cross-compilers--to see how well
> it works. Please let me know if you run into problems that you don't
> know how, or don't have time, to fix.
With GMP 4.
Ian Lance Taylor writes:
> I'm not entirely sure, but I don't think Jim said the opposite. He said
> that the way truncate works is machine dependent. I said that the
> output of truncate is machine independent. Since truncate is only
> defined for fixed-point modes, I think both statements are
Ian Lance Taylor writes:
> truncate has a machine independent meaning.
Yes, I guess with your definition below it does. It's interesting though that
Jim had said the opposite in the excerpts posted by Jeff:
And a later message from Jim:
Truncate converts a value from a larger to a smaller
Jeff Law writes:
> Ian Lance Taylor wrote:
> > Adam Nemet writes:
> >
> >
> >> I am trying to understand the checkin by Jeff Law from about 11 years ago:
> >>
> >>r19204 | law | 1998-04-14 01:04:21 -0700 (Tue, 14 Apr 1998) | 4 lin
Ian Lance Taylor writes:
> I agree that this patch looks wrong in todays compiler. There should be
> no need to call TRULY_NOOP_TRUNCATION if you are in a TRUNCATE anyhow.
Thanks.
Do you think we can assume this for TRUNCATEs in general or only for MIPS-like
TRUNCATEs?
I can't think of why it w
I am trying to understand the checkin by Jeff Law from about 11 years ago:
r19204 | law | 1998-04-14 01:04:21 -0700 (Tue, 14 Apr 1998) | 4 lines
* combine.c (simplify_rtx, case TRUNCATE): Respect value of
TRULY_NOOP_TRUNCATION.
Index: combine.c
==
Andrew Haley writes:
> We need something more like "I think Fred Bloggs knows gcc well enough
> to approve patches to reload" or "I am Fred Bloggs and I know gcc well
> enough to approve patches to reload."
And whom should such email be sent to? The SC is best reached on gcc@
but I don't think t
Revital1 Eres writes:
> Hello,
>
>> i386-pc-solaris:
>>
>> cc1: warnings being treated as errors
>> /export/home/arth/gnu/gcc.git/gcc/tree-ssa-loop-prefetch.c: In function
>> 'loop_prefetch_arrays':
>> /export/home/arth/gnu/gcc.git/gcc/tree-ssa-loop-prefetch.c:1589:7: error:
>
>> format '%ld' expe
In this testcase:
struct s
{
unsigned long a:2;
unsigned long b:40;
unsigned long c:22;
};
f (struct s s)
{
g (((unsigned long) (s.b-8)) + 8);
}
fold breaks the code. Specifically, after a few transformations we're asked
to fold this. (I changed the big constant t
Steven Bosscher writes:
> Is there a way to get the REG for a given regno? I am building a
> register renumbering map that is just a pair of unsigned int
> , but I can't figure out how to get the REG for
> new_regno without remembering a pointer to it myself. Is there an
> easier/better way?
reg
Jamie Prescott writes:
> > From: Adam Nemet
> > Jamie Prescott writes:
> > > static inline int set_prop(char const *path, char const *name,
> > > void const *data, int size)
> > > {
> > > int error
Jamie Prescott writes:
> static inline int set_prop(char const *path, char const *name,
> void const *data, int size)
> {
> int error;
>
> asm volatile ("int\t11\n\t"
> : "=a0" (error): "a0" (path), "a1" (name), "a2" (
John David Anglin writes:
> The same tests now fail on hppa. This is PR 39651. I'm fairly certain
> this was introduced by the following change:
I put this PR in the checkin that was just approved on gcc-patc...@. Please
close the bug if it fixes the failures on hppa too.
Adam
Adam Nemet writes:
> I am not exactly sure what has exposed this but the bug seems to be old.
> can_throw_external in except.c does not look at the branch delay slot (second
> entry in a SEQUENCE) to determine whether the insn may throw or not.
>
> In gcc.dg/cleanup-8.c for example
Adam Nemet writes:
> For two testresults now the cleanup tests are failing in both gcc and g++:
>
> http://gcc.gnu.org/ml/gcc-testresults/2009-04/msg01031.html
> http://gcc.gnu.org/ml/gcc-testresults/2009-04/msg00592.html
>
> I waited for another testresults because there w
For two testresults now the cleanup tests are failing in both gcc and g++:
http://gcc.gnu.org/ml/gcc-testresults/2009-04/msg01031.html
http://gcc.gnu.org/ml/gcc-testresults/2009-04/msg00592.html
I waited for another testresults because there were some bug fixes in this
area after the eh chang
Thank you very much. This was very informative.
Richard Sandiford writes:
> If we have an instruction:
>
> A: (set (reg Z) (plus (reg X) (const_int 0xdeadbeef)))
>
> we will need to use something like:
>
>(set (reg Y) (const_int 0xdead))
>(set (reg Y) (ior (reg Y) (cons
Richard Sandiford writes:
> Adam Nemet writes:
> > * Synthesizing multi-insns constants from const anchors make sense
> > regardless
> > whether the constant is used as an address so I am adjusting the cost system
> > to make those stick independent of the context.
Richard Sandiford writes:
> Adam Nemet writes:
> > In order for my CSE const anchor patch to work I needed to drastically lower
> > the cost of immediate addition in the MIPS backend. This was acceptable as
> > a
> > proof of concept but not in general of course.
In order for my CSE const anchor patch to work I needed to drastically lower
the cost of immediate addition in the MIPS backend. This was acceptable as a
proof of concept but not in general of course.
The problem is with "single-insn"/simple constants. We would also like these
to use const ancho
Jean Christophe Beyler writes:
> I set up your patch and I get an internal error on this test program:
You're right. I haven't handled the case properly when the constant itself
was an anchor constant (e.g. 0). Try this version.
Adam
* cse.c (get_const_anchors): New function.
Ramana Radhakrishnan writes:
> [Resent because of account funnies. Apologies to those who get this twice]
>
> Hi,
>
> > > This problem is reported every once in a while, all targets with
> > small
> > > load-immediate instructions suffer from this, especially since GCC
> > 4.0
> > > (i.e. since t
Steven Bosscher writes:
> On Sun, Mar 15, 2009 at 11:19 PM, Ramana Radhakrishnan
> wrote:
>> I'm not sure about the best way to fix this but I've filed this for
>> the moment as
>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39468
>
> This problem is reported every once in a while, all targets
Thanks for measuring these.
Laurent GUERBY writes:
> For bzip2 trunk regress badly in performance against 4.3.2
> but n32 is indeed relatively faster than 32 (still slower than 4.3.2).
> For gzip trunk matches 4.3.2 but n32 is slower than 32 and 64 even
> slower.
Last time I checked (on Octeon)
Adam Nemet writes:
> I am actually looking at something similar for PR33699 for MIPS. My plan is
> to experiment extending cse.c with putting "anchor" constants to the available
> expressions along with the original constant and then querying those later for
> constant
"Rahul Kharche" writes:
> GCSE won't help with your trimmed down example
>
> int main(void)
> {
> long a = 0xcafecafe;
>
> printf("Final: %lx %lx %lx\n", a, a+5, a+15);
> return EXIT_SUCCESS;
> }
>
> I believe Paolo's canon_reg solution together with tweaking
> rtx_cost of constants wi
Bernd Schmidt writes:
> Take a look at reload_cse_move2add.
I don't think that powerful enough; it requires the same destination
registers:
/* Try to transform (set (REGX) (CONST_INT A))
...
(set (REGX) (CONST_INT
Yoriko Komatsuzaki writes:
> Could you tell me why it doesn't work well around FRAME_GROWS_DOWNWARD
> on mips ?
I have a WIP patch for this but was holding back mostly because of stage3/4
and that I was trying to make FRAME_GROWS_DOWNWARD the default and I was
running into performance issues.
Th
Richard Sandiford writes:
> How about the patch below? I'll apply it in the next couple of days
> if there are no objections.
Thanks for patch. I also like the new comments you added.
Adam
-msym32 changes DWARF's address_size from 64 bits to 32 bits. This means that
while symbols are 64-bit (due to ELF64), target addresses in the debug info
are 32-bit.
There is support for this in DWARF of course in fact you can specify different
address_size for each compilation unit which nicely
Gerald Pfeifer writes:
> +January 27, 2008
2009 ;)
Adam
struct s
{
char a:4;
char b:8;
char c:4;
} __attribute__ ((packed))
is 3 bytes long because b gets pushed to the next byte boundary.
You would think that similarly:
struct t
{
char a:4;
short b:16;
char c:4;
} __attribute__ ((packed))
would come out to be 4 bytes long. However, t
Ralf Corsepius writes:
> So, my questions actually were aiming at
>
> * whether
> "gcc ... -nostdlib -r"
> and
> "gcc ... -nostdlib -Wl,-r"
> are equivalent
>
> * if the fact that "gcc -r" appears to work, can be exploited or whether
> this is a "random accident" and/or intentionally undocume
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> Ralf Corsepius <[EMAIL PROTECTED]> writes:
>
>> So what would you recommend: To use "gcc -r" or "gcc -Wl,-r" ?
>
> Ah, when you put the question like that, I would recommend "ld -r".
> This is the one case where you get no advantage from using the gcc
I am working on FRAME_GROWS_DOWNWARD for MIPS and I am seeing two performance
issues with the code generated. The first one has to do with the order how
expand_stack_vars places locals on the stack.
Consider this function (simplified from CSiBE's
replaypc-0.4.0.preproc:find-GOPs):
f ()
{
Hi David,
David Daney writes:
> gcc.target/mips/octeon-exts-2.c is failing when configured --with-arch=sb1
>
> Do you know if it is failing universally or only on non-octeon targets?
It's failing on little-endian. There is also another test that's failing on
64-bit little-endian. I will submit
Eric Botcazou writes:
> > Yes, the assert is really checking exactly that. Several pieces of
> > haifa-sched.c assume that the instruction has been recognized during
> > scheduler initialization to speed up checking if instruction is normal
> > or some kind of use/clobber/asm.
>
> What happens if
Eric Botcazou <[EMAIL PROTECTED]> writes:
>> Applying the patch Adam created and posted in the message below resolved
>> the issue and the compiler successfully bootstrapped:
>>
>> http://gcc.gnu.org/ml/gcc/2008-09/msg00139.html
>
> Thanks for reporting this. I now can close PR 37424.
>
>> There w
Maxim Kuvyrkov writes:
> I'm not 100% sure about current state of things, considering recent
> merge of sel-sched, but before that it was:
>
> set_priorities() -> priority() -> dep_cost() -> recog_memoized().
I don't think that was the case for all insns even before the patch. The only
new thin
Maxim Kuvyrkov writes:
> Yes, the assert is really checking exactly that. Several pieces of
> haifa-sched.c assume that the instruction has been recognized during
> scheduler initialization to speed up checking if instruction is normal
> or some kind of use/clobber/asm.
Thanks for the info but
haifa-sched.c:
2302/* Let the target filter the search space. */
2303for (i = 1; i < ready->n_ready; i++)
2304 if (!ready_try[i])
2305{
2306 insn = ready_element (ready, i);
2307
2308 gcc_assert (INSN_CODE (insn) >= 0
agreed with MTI
> beforehand (although I hadn't realised MTI themselves had written
> the specification). Having thought it over, I think it would be best
> if I stand down as a MIPS maintainer and if someone with the appropriate
> commercial connections is appointed instead. I&#
"Bingfeng Mei" <[EMAIL PROTECTED]> writes:
> Both -Dinhibit_libc and -DL_gcov are used as shown in our building log
> file. I guess -Dinhibit_libc is added because we used newlibc instead
> of glibc. I tried to grep these functions in newlibc and didn't find
> them. My question is how to enable g
"XU SHENG" <[EMAIL PROTECTED]> writes:
> int priv_dat __attribute__ ((section(".note"))) = MAGIC;
>
...
>
> It's clear to me that only section marked attribute with the
> startup of ".note" can be compiled to section with type SHT_NOTE in ELF
> file. Then only problem is assembler in g
Matt Lee writes:
> In any case, I am trying to optimize the case where there is clearly no
> aliasing. Your suggestion regarding movmemsi is interesting. I have not used
> this pattern before and assumed that it was required only when something
> special must be done to do block moves. In my archit
"Matt Lee" <[EMAIL PROTECTED]> writes:
> I am seeing poor scheduling in Dhrystone where a memcpy call is
> expanded inline.
>
> memcpy (&dst, &src, 16) ==>
>
> load 1, rA + 4
> store 1, rB + 4
> load 2, rA + 8
> store 2, rB + 8
> ...
Are you sure that there are no dependencies due to aliasing h
Sandra Loosemore <[EMAIL PROTECTED]> writes:
> #6 0x0875dc03 in rest_of_handle_combine ()
> at /scratch/sandra/mips-mainline/src/gcc-mainline/gcc/combine.c:1264
>
> ...
>
> Looks like a job for valgrind? But I'm out of time for working on
> this, at least for now. Can anyone else take a stab
Richard Kenner writes:
> Otherwise, if you have
>
> struct foo {int a: 32; int b: 32; };
> struct bar {int c: 32; int d: 32; };
>
> you have the fields A and C conflicting, which is wrong.
Well, that is where structure-field aliasing comes in. The two cannot
even alias for addressab
Richard Kenner writes:
> > I am glad to see we are converging toward implementation issues now!
> >
> > I am storing it in a new field under the alias_set_entry:
> >
> > get_alias_set_entry (TYPE_ALIAS_SET (t))->nonaddr_alias_set.
>
> Where T is which type?
Type of the expression passed to g
Richard Kenner writes:
> But there's also an implementation issue: where do you propose to *store*
> this fake alias set? There is no such field as DECL_ALIAS_SET.
I am glad to see we are converging toward implementation issues now!
I am storing it in a new field under the alias_set_entry:
ge
Eric Botcazou writes:
> For the Ada testcase:
>
> ;; s->i = 0
> (insn 7 6 0 p.adb:5 (set (mem/s/j:SI (reg/v/f:DI 59 [ s ]) [4 .i+0
> S4 A32])
> (const_int 0 [0x0])) -1 (nil))
>
> ;; *p = 1
> (insn 8 7 0 p.adb:6 (set (mem:SI (reg/v/f:DI 60 [ p ]) [2 S4 A32])
> (const_int 1 [0x1]))
Daniel Berlin writes:
> On 6/15/07, Adam Nemet <[EMAIL PROTECTED]> wrote:
> > get_alias_set and internally record_component_aliases makes
> > assumptions about the IR that are only valid in RTL.
>
> What is this assumption, exactly?
That non-addressable fields are al
get_alias_set and internally record_component_aliases makes
assumptions about the IR that are only valid in RTL. As a consequence
the constant 1 is propagated into the function call in the example
below (I found this issue with 4.1 but it is also present on trunk):
struct s
{
long long a:
Ben Elliston <[EMAIL PROTECTED]> writes:
> I see a couple of solutions, but would like to discuss them here before
> working on a patch:
>
> 1. have the bprob.exp test driver create the appropriate directory
>tree on the target (and remove it when finished); or
>
> 2. set GCOV_PREFIX when runni
Jim Wilson writes:
> Yes, it looks like fixing the combiner problem would make it possible to
> remove the mistaken mode checks.
Thanks very much, Jim. I will work toward removing these then.
Adam
Hi,
I am trying to understand why the MIPS backend's handling of
comparison modes seems to be different from what rtl.texi says:
The mode of the comparison operation is independent of the mode
of the data being compared. If the comparison operation is being tested
(e.g., the first operand
72 matches
Mail list logo
