On 06/03/14 21:03, Vladimir Makarov wrote:
On 03/06/2014 03:14 PM, Paulo J. Matos wrote:
Still, would you accept a patch to mark this flag as an optimization?
I think we should.
Submitted to gcc-patches for approval.
--
PMatos
On 06/03/14 15:15, Vladimir Makarov wrote:
On 03/06/2014 08:55 AM, Paulo Matos wrote:
Hi,
Upon noticing ira-hoist-pressure in `gcc --help=optimizers` and not
ira-loop-pressure,
I am wondering why the latter is not marked as an Optimization in common.opt:
fira-loop-pressure
Common Report Var(f
On 18/01/14 20:11, pins...@gmail.com wrote:
On Jan 18, 2014, at 12:04 PM, "Paulo J. Matos" wrote:
On 17/01/14 17:36, Eric Botcazou wrote:
I am not implying that this is a GCC bug, unless you think
WORD_REISTER_OPERATIONS should have avoided the creation of such
paradoxical su
Hello,
Do we care if trunk doesn't compile successfully with
--enable-werror-always?
Do we want to fix things like:
../../../../gcc-trunk/fixincludes/server.c: In function ‘server_setup’:
../../../../gcc-trunk/fixincludes/server.c:195:10: error: ignoring
return value of ‘getcwd’, declared wit
On 17/01/14 17:36, Eric Botcazou wrote:
I am not implying that this is a GCC bug, unless you think
WORD_REGISTER_OPERATIONS should have avoided the creation of such
paradoxical subreg.
No, that's precisely the contrary, WORD_REGISTER_OPERATIONS tends to create
paradoxical subregs.
I might th
On 10/10/13 20:52, David Malcolm wrote:
I've added detailed information on the project to the wiki as:
http://gcc.gnu.org/wiki/JIT
and added a link to that page to the front page's "Current Projects"
section.
For reasons unknown to me, check-parallel-jit has to be issues inside
build/jit/
On 27/06/2013 16:02, Mikael Pettersson wrote:
Paulo Matos writes:
That explains why GCC removes the condition but the main issue of the memset
recursion still stands.
Known problem. See GCC PR56888.
Thanks for the reference Mikael, that's exactly it.
--
Paulo Matos
On 08/05/13 23:10, Andreas Schwab wrote:
"Paulo J. Matos" writes:
Shouldn't we expect ires to be -1 (STORE_FLAG_VALUE)
??? Boolean expressions in C evaluate to 0/1.
Andreas.
Agreed, I worked till too late yesterday, I am sorry.
Further to this matter, can you explai
On 08/05/13 21:29, Andreas Schwab wrote:
"Paulo J. Matos" writes:
As I expected. That doesn't sound good
In which way is it not good?
Andreas.
Shouldn't we expect ires to be -1 (STORE_FLAG_VALUE) and therefore the
condition of the if be false if everything is
On 08/05/13 14:54, Andreas Schwab wrote:
I'm getting "1 != ((2 >= 2 ? -1 : 0)" with 4.7.3.
Andreas.
As I expected. That doesn't sound good but I am unsure on what to do
about it. I will investigate the case further tomorrow.
I expect m68k to also fail the vector-compare-1.c gcc test, is t
Mikael,
I haven't really tried m68k and I can't say I know anything about it but
it will only be affected by this issue I am seeing if it generates
instructions of the form:
(set (reg:BI ...)
(:BI (reg:SI ...) (const_int ...)))
If you have something like this then as soon as you expand t
On 22/12/12 10:13, Alexandre Oliva wrote:
On Dec 20, 2012, "Paulo Matos" wrote:
This doesn't look sensible to me (but I might be overlooking a reason why we
want to do so) in the context of cselib_record_sets, however, I think
cselib_record_sets should instead have the patch applied:
- for_e
On 24/10/12 17:30, Joseph S. Myers wrote:
On Wed, 24 Oct 2012, Paulo Matos wrote:
Conversions of target macros to hooks are generally of interest.
I don't think we want a stream-of-consciousness sequence of messages about
successive aspects of the issue.
I apologize if my messages became a nu
On 09/08/12 17:54, Aaron Gray wrote:
Hi,
I have developed several patches for GCC and am wondering as a purely
open source non commercial developer whether there are any issues
regarding getting patches into GCC. Do I need to sign an agreement at
all ?
If you want the copyright assignment for
Hi,
Can someone please clarify some policies with GCC contribution. If I
have a patch with a GCC enhancement, do I need to obtain a bug report
for it and then submit the patch or I can submit a patch to the patch
mailing list without opening a bug report?
Cheers,
--
PMatos
loyer disclaimer, if an employer or school
owns work created by the developer. "
Cheers,
Paulo
--
Patrick
On 08/02/2012 09:14 AM, Paulo J. Matos wrote:
Hello,
Could someone please send me the copyright assignment forms for single
contributions and for all future contribution
Hello,
Could someone please send me the copyright assignment forms for single
contributions and for all future contributions?
Cheers,
--
PMatos
On 26/07/12 15:04, Joseph S. Myers wrote:
On Thu, 26 Jul 2012, Paulo J. Matos wrote:
My target has 16bit chars.
As I explained before, support for such targets is extremely limited and
bitrotten (this applies whether it is BITS_PER_UNIT, CHAR_TYPE_SIZE or
both that are not 8) and a large
On 26/07/12 13:27, Richard Guenther wrote:
Why would the fill value in a memset call be required to fit in a host char?
Obviously because of the implementation detail of its caller.
Richard.
Richard, I am sorry if I was not more clear. I understand that this is
required because the caller
Hi,
My target has 16bit chars.
What I am seeing is that in a memset call, the call is not inlined by
GCC whenever fill value is bigger than host char.
This seems to be due to the code (GCC 4.6.5) in target_char_cast
(builtins.c), called from expand_builtin_memset_args:
static int
target_cha
On 12/07/12 12:19, Richard Guenther wrote:
Look into the tree dumps and look where the ={v} disappears. That
will point to the pass that breaks it and eventually help track down the
fixing patch.
Thanks for the tip Richard. Tracked it down to PHI prop pass in
tree-ssa-phiprop.c, not yet wha
Hello,
As far as I know 4.3 and 4.4 are no longer maintained and 4.3.6 and
4.4.7 were the last of their respective lines however if someone is kind
enough to look at the following, I would be extremely grateful. I found
a bug in 4.3.6 and 4.4.7 fixed in 4.5.0 but I am having a hard time
pinpo
The output is still the same but the spill is fixed in 4.7.1.
On 14/06/12 13:47, Paulo J. Matos wrote:
Hi,
I found a problem with my port where IRA generates a spill error. After
looking at the logs I get this kind of output for the best class for the
pseudo regs:
Pass 0 for finding pseudo
I forgot to mention this is in 4.7.0.
4.6.3 happily assigns the right classes to the registers. I wonder if
there's any new macro in 4.7 that I haven't defined...
On 14/06/12 13:47, Paulo J. Matos wrote:
Hi,
I found a problem with my port where IRA generates a spill error. After
Hi,
I found a problem with my port where IRA generates a spill error. After
looking at the logs I get this kind of output for the best class for the
pseudo regs:
Pass 0 for finding pseudo/allocno costs
a2 (r30,l0) best NO_REGS, allocno NO_REGS
a3 (r29,l0) best NO_REGS, allocno NO_REG
On 21/05/12 15:21, Christian Bruel wrote:
Options not explicitly described in the compiler before their use in a
spec rules are now rejected. So you probably need to describe it into
your target optimization file, (something like xap.opt).
OK, thanks for letting me know about this.
Cheers,
On 17/05/12 17:08, Richard Henderson wrote:
My question is, why are you generating compares in two different
modes early, before compare-elim runs? If you hadn't done that,
your redundant compare would already be eliminated.
I just looked at the rx code and it seems to be doing something sim
On Thu, 17 May 2012 09:08:26 -0700, Richard Henderson wrote:
> My question is, why are you generating compares in two different modes
> early, before compare-elim runs? If you hadn't done that, your
> redundant compare would already be eliminated.
>
Good question. I tried to follow the example s
Hi,
I am looking at a missed optimization and I think this is something that
could be added to compare-elim, if it's not already done somewhere else.
I have a double word comparison to zero, so in C it's:
int le(long a) { return a <= 0; }
My expand uses the following transformation (in my cur
,
Manuel.
On 14 May 2012 10:49, Paulo J. Matos wrote:
Hi Alberto,
As far as I understand it you want to know if a statement was expanded from
a preprocessor macro, right?
This isn't possible. The preprocessor is a separate thing altogether and I
doubt any preprocessing information remain
Hi Alberto,
As far as I understand it you want to know if a statement was expanded
from a preprocessor macro, right?
This isn't possible. The preprocessor is a separate thing altogether and
I doubt any preprocessing information remains for the compiler proper to
deal with.
Cheers,
Paulo M
Hi,
MULTILIB_OPTIONS containing options defined in DRIVER_SELF_SPEC seemed
to be fine in GCC46 but fail in GCC47.
For example, I have:
xap.h:
#define DRIVER_SELF_SPECS \
"%{help:-v} %"%{mno-args-span-regs-and-mem:-mno-split-args}
%"%{mno-inline-block-copy-mod
Forget about this question. Doesn't make sense at all.
I wonder if the thing I drank during lunch was really water...
On 09/05/12 14:40, Paulo J. Matos wrote:
Hi,
While debugging an issue related to my movmem rule, I noticed that
fwprop seems to be doing some really strange.
The pr
Hi,
While debugging an issue related to my movmem rule, I noticed that
fwprop seems to be doing some really strange.
The problem occurs when setting the argument to the block copy
instruction. The full C code is:
int **
t25 (int *d, int **s)
{
memcpy (d, *s, 16);
return s;
}
Before fwpr
On 09/05/12 11:53, paul_kon...@dell.com wrote:
He was showing the RTL expansion of the example he gave:
Ah, right. I interpreted it as if it was what the movmem expanded to.
--
PMatos
On 08/05/12 21:57, Jan Hubicka wrote:
In expanded form it is
(set (reg5) (const 10))
(parallel [(set (reg2) (const 0))
(set (reg0) (plus (reg3) (reg5)))
(set (reg1) (plus (reg4) (reg5)))
(set (mem (reg3)) (mem (reg4)))])
(set (reg0) (plus (reg0) (cons
On 04/05/12 19:48, Ian Lance Taylor wrote:
The i386 rep_movqi insn is an example:
(define_insn "*rep_movqi"
[(set (match_operand:P 2 "register_operand" "=c") (const_int 0))
(set (match_operand:P 0 "register_operand" "=D")
(plus:P (match_operand:P 3 "register_operand" "0")
On 04/05/12 14:44, Ian Lance Taylor wrote:
I agree that there is something wrong here. I agree that as written
the constraints for operands 0, 1, and 2 should have a '+'.
That said, a '+' constraint is most useful for a pattern that expands
into multiple instructions. I think this would be bet
Hi,
I was just trying to understand exactly what constraint modifiers + and
= mean. I have read the manual but I am uncertain about their meaning in
the context of the following rule (without any modifiers):
Expand generates:
(define_insn_and_split "movmem_long"
[(set (match_operand:QI 2 "
On 30/04/12 13:01, Peter Bigot wrote:
I would like to see the technical details, if your code is released somewhere.
Hi Peter,
Sorry for the delay.
The code is not released, however I can send you a patch against GCC
4.6.3 sources (our GCC 4.7.0 port is not yet stable) of our changes and
wi
Peter,
We have a working backend for an Harvard Architecture chip where
function pointer and data pointers have necessarily different sizes. We
couldn't do this without changing GCC itself in strategic places and
adding some extra support in our backend. We haven't used address spaces
or any
On 27/04/12 11:49, Richard Guenther wrote:
Yes, it inlines it. You may want to look at s390 which I believe has
a similar block-copy operation.
Richard.
I looked at s390 and even though the block copy instruction seems
similar ours is much more restrictive since it expects values in
speci
On 27/04/12 11:49, Richard Guenther wrote:
It feels to me that GCC46 version is better:
* no branch to subroutine memcpy;
* less stack usage (argument to enterl);
So, using our block copy (bc2) instruction is an optimisation, don't you
think?
Yes, it inlines it. You may want to look at s390 w
On 27/04/12 09:21, Richard Guenther wrote:
This differs from what GCC47 does and seems to work better.
I would like help on how to best handle this situation under GCC47.
Not provide movmem which looks like open-coded and not in any way
"optimized"?
Thanks Richard, however I don't understan
Hi,
I am facing a problem with the GCC47 register allocation and my
movmemqi. GCC46 dealt very well with the problem but GCC47 keeps
throwing at me register spill failures.
My backend has very few registers. 3 chip registers in total (class
CHIP_REGS), one of them (XL) is used for memory ref
On 03/04/12 15:04, Ian Lance Taylor wrote:
> "Paulo J. Matos" writes:
>
>
> Hmmm, you're right, I didn't notice those. You said that on your system
> QImode is 16 bits. These modes are being used to efficiently load
> 16-bit, 32-bit, and 64-bit values, in
On 30/03/12 05:11, Ian Lance Taylor wrote:
"Paulo J. Matos" writes:
I am porting my backend to GCC47 and have been jumping through some
hurdles. libgcc is trying to compile unwind*.c files which I can't
remember being there for GCC46.
They were there. In 4.6 they
On Mon, 26 Mar 2012 11:10:11 -0700, Ian Lance Taylor wrote:
>
>> *** Configuration xap-local-xap not supported
>
> You will have to find out where that last error message is coming from.
> It's not happening because of errors in configure tests. It's most
> likely coming from libgcc/config.host
Hi,
I am porting my backend to GCC47 and have been jumping through some
hurdles. libgcc is trying to compile unwind*.c files which I can't
remember being there for GCC46. I deduce this files have to do with
exception support GCC47 seems to want to make exceptions mandatory even
though my backe
Hello,
I am porting my backend to GCC47 and during libgcc configuration I get:
configure:4511: checking whether to use setjmp/longjmp exceptions
configure:: /home/pm18/p4ws/pm18_binutils/bc/main/result/linux/
intermediate/FirmwareGcc47Package/./gcc/xgcc -B/home/pm18/p4ws/
pm18_binutils/bc/main/res
Vladimir,
Thanks for for the explanation.
Cheers,
Paulo Matos
On 23/03/12 16:08, Vladimir Makarov wrote:
On 03/23/2012 11:04 AM, Paulo J. Matos wrote:
Hello,
I am trying to find exactly what happened to IRA_COVER_CLASSES in
gcc47. From what I have seen it seems that it was simply removed
Hello,
I am trying to find exactly what happened to IRA_COVER_CLASSES in gcc47.
From what I have seen it seems that it was simply removed. Does the
register allocator now automatically computes the cover classes?
Cheers,
--
PMatos
On 22/03/12 13:58, Jakub Jelinek wrote:
On Thu, Mar 22, 2012 at 01:36:58PM +, Paulo J. Matos wrote:
I notice that on ftp://ftp.gnu.org/pub/pub/gnu/gcc/gcc-4.7.0/
there's no gcc-core tarball. Is this still going to show up or will
it not be released anymore?
They won't be provid
I notice that on ftp://ftp.gnu.org/pub/pub/gnu/gcc/gcc-4.7.0/
there's no gcc-core tarball. Is this still going to show up or will it
not be released anymore?
On 22/03/12 09:49, Richard Guenther wrote:
Status
==
The GCC 4.7.0 release will be announced soon. The branch is open for
regres
I notice that on ftp://ftp.gnu.org/pub/pub/gnu/gcc/gcc-4.7.0/
there's no gcc-core tarball. Is this still going to show up or will it
not be released anymore?
On 22/03/12 09:49, Richard Guenther wrote:
Status
==
The GCC 4.7.0 release will be announced soon. The branch is open for
regres
On 20/03/12 10:30, Jakub Jelinek wrote:
>
Like any other builtin expander? There are many dozens of examples in
builtins.c. It is called with the tree argument, so you verify it, complain
if the argument is not the one you are expecting, and just expand it as the
symbol instead of expanding the
On Mon, 19 Mar 2012 22:49:39 -0700, Ian Lance Taylor wrote:
>
> I'm not sure what you are folding the builtin to, but perhaps you could
> retain a reference to the function.
>
I am folding the function call __function_size(foobar) to a new symbol
foobar@size. The reference to function foobar d
Hi,
I have builtin __function_size(foobar) that is applied to functions.
This should be folded to a symbol foobar@size.
The problem comes when I mark in the fold_builtin function in my backend
that DECL_PRESERVE(foobar) = 1;
The reason I need to do this is so that foobar is not removed if we
h
On Fri, 10 Feb 2012 11:00:43 -0800, Richard Henderson wrote:
> On 02/10/2012 08:57 AM, Paulo J. Matos wrote:
>> However, there's a failure to combine looking like: (parallel [
>> (set (reg:QI 1 AL)
>> (ior:QI (mem/c/i:QI (re
On Fri, 10 Feb 2012 16:57:48 +, Paulo J. Matos wrote:
> However, duplicating the instructions and inverting operand order seems
> to defeat the purpose of '%'. So, what's the catch? Or is it a genuine
> bug?
I just understood my miss understanding above. '%&#
Hi,
I just noticed something strange with my iorqi3 rule.
I have the following:
(define_insn "iorqi3"
[(set (match_operand:QI 0 "register_operand" "=c")
(ior:QI (match_operand:QI 1 "register_operand" "%0")
(match_operand:QI 2 "general_operand" "cwmi")))
(clobber (reg
Hi,
The docs state:
`cbranchmode4'
Conditional branch instruction combined with a compare instruction.
Operand 0 is a comparison operator. Operand 1 and operand 2 are the first
and second operands of the comparison, respectively. Operand 3 is a
label_ref that refers to the label to jump to
Hi,
In order to pursue an optimization I am explicitly defining a cbranchhi4
and manually expanding to calls to cbranchqi4 or similar.
Do I need to attach probabilities notes to jumps emitted during the
expand phase?
Cheers,
--
PMatos
Hi,
I am developing a new pass and looking for suggestions on the best way
to record in a data structure which regs and subregs I have seen and
which mode they are in through the insn chain so I know if I find
duplicates.
Any suggestions on the best way to do this?
Are there any rtx hashes a
Hi,
I have the very simple:
volatile unsigned int SOME_REGISTER;
volatile unsigned long ANOTHER_REGISTER;
void foo_bar(void)
{
SOME_REGISTER = 0;
ANOTHER_REGISTER = 0;
}
causing me some headaches: int is QImode, long is HImode.
Using gcc-4.6.2, in 175r.fwprop2 I have:
(insn 6 2 7 2 (parall
On 13/12/11 14:47, Ian Lance Taylor wrote:
outgoing_args_size is the number of bytes required by called functions.
In your question above, the answer is no; x is an incoming argument. If
you write
extern foo(int);
void bar(void) { foo (1); }
then the outgoing_args_size of bar is sizeof(int), b
Hi,
I am finding slightly confusing the difference between
outgoing_args_size and pretend_args_size.
I think I understand pretend_args_size, at least on the specific case of
my port. The first two words of arguments go into two register the
remaining goes into the stack. However, if the firs
On 01/11/11 02:43, Hans-Peter Nilsson wrote:
Not obvious or maybe I was unclear as to what I alluded?
In the below insn-bodies, "sub" is the insn that sets cc0 as a
side-effect.
Supposed canonical form :
(parallel
[(set cc_reg) (compare ...))
(set destreg) (sub ...))])
and:
(parallel
[(
On 31/10/11 05:36, Hans-Peter Nilsson wrote:
BTW, I
don't think it helps that someone decided the canonical form of
a parallel that includes a CC-setter must have the CC-setting
*first* (contrasting with the position of clobbers)...
How did you reach this conclusion?
--
PMatos
On 29/10/11 18:33, Peter Bigot wrote:
On Sat, Oct 29, 2011 at 10:58 AM, Richard Henderson wrote:
On 10/29/2011 05:41 AM, Peter Bigot wrote:
It seems cc0 should probably still be preferred for CISC-style
architectures like the MSP430. I'll give that approach a try.
I think that's somewhat un
On 28/10/11 17:59, Richard Henderson wrote:
On 10/28/2011 06:49 AM, Peter Bigot wrote:
I'm inclined to follow sparc's lead, but is one or another of the choices
more likely to help combine/reload/etc do a better job?
I don't know.
In the case of RX, we don't model CC_REG until after reload, s
On 23/10/11 22:21, Richard Henderson wrote:
On 10/21/2011 05:49 PM, paul_kon...@dell.com wrote:
There are lots of parts of the compiler that don't optimize well when an insn
has more than one output. For the normal insn, just clobber the flags; don't
include a second SET.
Yes, but... isn't
On 21/10/11 22:41, Richard Henderson wrote:
On 10/21/2011 10:15 AM, Paulo J. Matos wrote:
So I have implemented the nadd and addc as:
(define_insn "negqi2"
[(set (match_operand:QI 0 "register_operand" "=c")
(neg:QI (match_operand:QI 1 "register
On 19/10/11 01:48, paul_kon...@dell.com wrote:
From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Richard
Henderson
On 10/17/2011 03:50 AM, Paulo J. Matos wrote:
...
(for example, it would be ok to output negqi2, xorqi3 and
addc_internal since xorqi3 only sets N and Z, not
On 21/10/11 10:02, Paolo Bonzini wrote:
On 10/20/2011 07:46 PM, Paulo J. Matos wrote:
However, it failed to compile libgcc with:
../../../../../../../devHost/gcc46/gcc/libgcc/../gcc/libgcc2.c:272:1:
internal compiler error: in df_uses_record, at df-scan.c:3178
This feels like a GCC bug. I
On 20/10/11 18:12, Joern Rennecke wrote:
Or just change the constraint to "+c" .
After trying Ulrichs suggestion and getting it to work I decided to give
yours a try since it looked cleaner using +c and dups elsewhere.
However, it failed to compile libgcc with:
../../../../../../../devHost
On 20/10/11 16:25, Ulrich Weigand wrote:
When reload looks at the above pattern, it will see just
two operands, both of which are output-only. So when it
decides to reload one of the operands, it will only provide
an output reload, no input reload.
For operands that are actually used for both
On 20/10/11 15:06, Anitha Boyapati wrote:
Firstly, aren't discriminators introduced in DWARF 4? Little more
digging shows that the following fix is missing in 4.6.1 release. It
breaks the current dwarf2 parsers/readers. I think it is worth filing
a bug.
Anitha, if you only want dwarf2 produce
Hi,
And by rules of the game, I mean the semantics of the insn chain.
In comes in the sequence of a previous post where I am splitting a neghi
operation like this:
op0 = negHI(op1)
expands to:
op0 = op1
op0_HIGH = xorQI(op0_HIGH, -1)
parallel(
op0_LOW = negQI(op0_LOW)
op0_HIGH = add(op
On 19/10/11 00:10, Richard Henderson wrote:
The thing that's almost certainly missing is that the NAND pattern
must SET your flags register, not simply clobber it. Otherwise the
dependency between the ADDC and the NAND will never be created properly.
I understand that there's a missing SET o
On 18/10/11 06:12, vikramsp wrote:
In my .md file there is an insn
(define_insn abssf2
(clobber (match_scratch 2 ""))
the %2 register is allocated as r0 in the real code.
My problem is that i want other than r0 to be allocated
for operand 2.
Please help how to do t
On 17/10/11 17:20, Andrew Pinski wrote:
On Mon, Oct 17, 2011 at 3:50 AM, Paulo J. Matos wrote:
addc_internal looks like:
(define_insn "addc_internal"
[(set (match_operand:QI 0 "nonimmediate_operand" "=c")
(plus:QI
(plus:QI
(lt
Hi,
To negate a double word (HImode) register, I used to take the
instruction all the way to assembly generation and then expand into
three assembly instructions like so:
xor %t0, # ; invert bits in top word of op0
nadd %b0, #0; negate bottom bits of op0
addc %t0, #0; add ca
On 06/10/11 15:41, Paulo J. Matos wrote:
Suddenly bugzilla went down.
Am I the only one seeing this?
Opps, now sorted.
--
PMatos
Suddenly bugzilla went down.
Am I the only one seeing this?
--
PMatos
Ian Lance Taylor writes:
> pa...@matos-sorge.com (Paulo J. Matos) writes:
>
>> I am trying to find where IRA, is deleting trivial insn like:
>> (set r1 r1)
>
> Search for "Discard obvious no-ops" in the function reload in the file
> gcc/reload1.c.
Thanks, that's exactly it.
--
PMatos
Hi,
I am trying to find where IRA, is deleting trivial insn like:
(set r1 r1)
The problem I am facing is that I have managed to convince GCC to handle
moves that clobber RCC like:
(parallel [(set reg1 reg2) (clobber rcc)])
However, I am getting loads of insn like:
(parallel [(set r1 r2) (clobb
"Amker.Cheng" writes:
>
> Thanks for replying.
> Sorry if I misunderstood anything below, and please correct me.
>
> insn 882 : cc <- compare (r684, 0)
> jump_insn 883 : if (cc != 0) goto insn 46
> insn 49: r291 <- r684
> ..
> insn 46
>
> cc contains the result of subtract
"Amker.Cheng" writes:
> (insn 882 881 883 96 (set (reg:CC 24 cc)
> (compare:CC (reg:SI 684 [ default_num_contexts ])
> (const_int 0 [0]))) core_main.c:265 211 {*arm_cmpsi_insn}
> (nil))
>
>
> The insn49 should be propagated with conditional const from insn882
> and jump_i
On 26/09/11 17:23, Ian Lance Taylor wrote:
The function added_clobbers_hard_reg_p is a generated function. So
another approach would be some sort of attribute which directs the
generator (genemit) to ignore certain hard registers.
This definitely sounds like the best approach for my specific
Hi,
I was tracking down an assertion failure in GCC which occured while I
was trying to bend some GCC constraints.
I came accross this function `insn_invalid_p', which calls
`added_clobbers_hard_reg_p' and before calling it, has the comment:
/* If we have to add CLOBBERs, fail if we have to
On Fri, 23 Sep 2011 09:30:48 -0400, amylaar wrote:
> Hiding the flags register would mean it is not represented in the rtl at
> all. You can have combined compare-branch instructions. Of course,
> going that route would mean that the model you present to GCC is even
> further from the hardware th
On 22/09/11 22:15, Richard Guenther wrote:
Btw, I think this is an old bug that has been resolved. Did you make sure to
test a recent 4.6 branch snapshot or svn head?
My hopes were high but unfortunately it is not fixed yet.
git head 36181f98 still generates the same unexpected code.
Cheers
On 23/09/11 08:21, Joern Rennecke wrote:
Quoting "Paulo J. Matos" :
My addition instruction sets all the flags. So I have:
This is annoying, but can be handled. Been there, done that.
dse.c needs a small patch, which I intend to submit sometime in the future.
Ok. Actually I
On 23/09/11 12:33, Paulo J. Matos wrote:
On 22/09/11 22:15, Richard Guenther wrote:
Btw, I think this is an old bug that has been resolved. Did you make
sure to
test a recent 4.6 branch snapshot or svn head?
Should have tested git head. Compiling git head now to check the current
status of
On 22/09/11 22:15, Richard Guenther wrote:
Btw, I think this is an old bug that has been resolved. Did you make sure to
test a recent 4.6 branch snapshot or svn head?
Should have tested git head. Compiling git head now to check the current
status of this issue.
--
PMatos
Hi,
After the discussion about the use of CCmode in:
http://gcc.gnu.org/ml/gcc/2011-07/msg00303.html
I am trying to ditch support for the only cc0 attr and add support for
CC_REG.
There are two issues that are making the situation more complicated,
both of similar nature.
My addition instr
On 21/09/11 15:21, David Brown wrote:
And since this
situation would not occur in real code (at least, not code that is
expected to do something useful other than test the compiler's code
generation), there is no harm in making sub-optimal object code.
Actually the reason why I noticed this is
On 21/09/11 08:03, David Brown wrote:
Asking to read it by a volatile read does not
change the nature of "foo" - the compiler can still implement it as a
compile-time constant.
But since I am accessing the data through the pointer and the pointer
qualifies the data as volatile, shouldn't the c
On 20/09/11 17:35, Ian Lance Taylor wrote:
I agree that this looks like a bug. Please file a bug report marked as
a regression.
Ian
Thanks. Reported as 50472 even though I am just reading Davids post and
he is convincing me that this might not be a bug after all, however, it
is still behav
1 - 100 of 347 matches
Mail list logo
