Hi,
I would like to experiment with modifications to the instruction flow
during scheduling. One motivation for doing that is the combining of
contiguous loads like was discussed here:
http://gcc.gnu.org/ml/gcc/2010-12/msg00153.html
I've seen that the scheduler itself does some modifications to t
Hi,
I've been playing with the vectorizer for my port, and of course I use
the testsuite to check the generated code. I fail to understand some
of the FAILs I get. For example, in slp-3.c, the test contains:
/* { dg-final { scan-tree-dump-times "vectorized 3 loops" 1 "vect" {
xfail vect_no_align
Hi Ira,
thanks for your answer, however:
On 31 May 2011 08:06, Ira Rosen wrote:
>> This test fails for me because I get 4 vectorized loops instead of 3.
>> There are multiple other tests that generate more vectorization then
>> expected. I'd like to understand the reason for these failures, but
Hi,
My port hits this assertion in loop-iv.c:799:
gcc_assert ((*inner_mode == *outer_mode) != (*extend != UNKNOWN));
It's in the function get_biv_step:
static bool
get_biv_step (df_ref last_def, rtx reg, rtx *inner_step,
enum machine_mode *inner_mode, enum rtx_code *extend,
Hi
On 25 October 2011 10:00, Jakub Jelinek wrote:
> On Mon, Oct 24, 2011 at 11:12:29PM -0400, David Miller wrote:
>> While working on some test cases I noticed that the 'fsmuld'
>> instruction on sparc was not being matched by the combiner for
>> things like:
>>
>> double fsmuld (float a, float b
On 25 October 2011 16:45, Joseph S. Myers wrote:
> On Tue, 25 Oct 2011, Frederic Riss wrote:
> Contracting (which is independent from excess precision) is controlled by
> -ffp-contract. This can operate at the very latest at the GIMPLE level
> (it needs to know about origina
Hi,
in builtins.c:expand_builtin_setjmp_receiver I see the following code:
827 /* Now put in the code to restore the frame pointer, and argument
828 pointer, if needed. */
829 #ifdef HAVE_nonlocal_goto
830 if (! HAVE_nonlocal_goto)
831 #endif
832 {
833 emit_move_insn (virtual_stack_
Hi Ian,
On 19 October 2010 15:31, Ian Lance Taylor wrote:
> It should not be necessary to use STARTING_FRAME_OFFSET when using
> virtual_stack_vars_rtx, as it should be added in by the vregs pass. See
> instantiate_new_reg, and note that var_offset is set to
> STARTING_FRAME_OFFSET.
Yes, but he
Hi,
Is it possible to describe multi-register values in RTL when the
subparts of the value aren't stored in consecutive registers? For
example having a DI value constructed from 2 unrelated SI registers
(without losing the semantic of the original DI value) ?
Thanks a lot,
Fred
On 21 October 2010 16:49, Nathan Froyd wrote:
>> Is it easy to test lm32 on some simulator?
>
> lm32 has a gdb simulator available, so it should be fairly easy to write
> a board file for it if one doesn't already exist.
>
> Unfortunately, building lm32-elf is broken in several different ways
> ri
On 22 October 2010 20:17, Ian Lance Taylor wrote:
> Frederic Riss writes:
>> OK... what's the best way forward on this? Do we just leave it as it
>> is and wait until an official port needs complains about it? Should it
>> be filled in bugzilla?
>
> Did you just h
Hi,
The constant propagation pass propagates constants into the
instructions that accept immediates. I'm trying to find if there's
some CSE pass in GCC that would be able to undo this effect when the
constant is used more than once in the function. I looked at the CSE
code (4.5 branch) and I don't
Hi Jeff,
On 26 October 2010 16:22, Jeff Law wrote:
> There is currently no pass which does "un-cse"; however, using insn
> splitting and operand costing and suitable insn constraints/predicates you
> can usually arrange to avoid expensive constants in places where it makes
> sense.
The thing is
On 27 October 2010 21:21, Jeff Law wrote:
> On 10/27/10 12:15, Frederic Riss wrote:
>> On 26 October 2010 16:22, Jeff Law wrote:
>>
>> The thing is the cprop pass doesn't look at insn costs while doing its
>> job AFAICS. I'm interested to see how insn s
On 8 December 2010 00:12, Jeff Law wrote:
> On 12/07/10 12:29, Frédéric RISS wrote:
>>
>> Le mardi 07 décembre 2010 à 06:18 -0700, Jeff Law a écrit :
>>>
>>> On 12/06/10 15:07, Ian Lance Taylor wrote:
>>> Given the two loads don't have a def-use data dependency combine won't
>>> ever get the oppor
On 8 December 2010 15:39, Jeff Law wrote:
> On 12/08/10 01:40, Frederic Riss wrote:
>> Sorry, I think I wasn't clear. I didn't mean constraints in term on
>> RTL template constraints, but 'constraints' coming from the new DI
>> destination of the load.
On 8 December 2010 17:37, Jeff Law wrote:
> On 12/08/10 09:18, Frederic Riss wrote:
>>
>> OK, I see your point, but I tend to think the the odds of the register
>> allocator being able to coalesce the additional DI->SI moves in the
>> pre-IRA approach are by far
Hi,
I tried to enable LTO on my port, but failed to do so. On a stupid
example, I get:
$ k1-gcc -flto toto.o print.o
lto1: internal compiler error: compressed stream: data error
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
lto-wrapper: /work1/fr
Hi Dave,
On 14 December 2010 15:48, Dave Korn wrote:
> This symptom usually means that the assembler is padding the section
> containing the compressed data when it generates the IR-containing .o file.
> There is no record within the compressed data stream of how long it is
> supposed to be(*),
On 3 January 2011 08:05, Eric Botcazou wrote:
>> Any idea why these results would be so poor ?
>
> Because of your bootstrap settings, more precisely --enable-checking=all.
I was wondering about that lately. Should testsuite failures with
--enable-checking=all be reported? IIRC, the 4.5 branch wo
Hi,
I've seen GCC emit many unneeded moves in very simple cases when
handling double floating point values. I tracked this down to the
lower-subreg pass that splits DF->DF moves into DF->(2*SI)->DF moves.
I suppose that the introduced mode changes prevent the IRA from
coalescing the moves and thus
On 6 January 2011 10:27, Frederic Riss wrote:
> Hi,
>
> I've seen GCC emit many unneeded moves in very simple cases when
> handling double floating point values. I tracked this down to the
> lower-subreg pass that splits DF->DF moves into DF->(2*SI)->DF moves.
> I
On 6 January 2011 15:27, Ian Lance Taylor wrote:
> Frederic Riss writes:
>> ../gcc/testsuite/gcc.c-torture/execute/ieee/930529-1.c:27:1: error:
>> unrecognizable insn:
>> (insn 45 2 46 2
>> ../gcc/testsuite/gcc.c-torture/execute/ieee/930529-1.c:2 (set
>> (subre
On 6 January 2011 16:14, Ian Lance Taylor wrote:
> Frederic Riss writes:
>> I managed to get thinks going by constraining MODES_TIEABLE_P and
>> adding 2 patterns of the form:
>>
>> [(set (subreg:SI (match_operand:DF 0 "register_operand" "=r") 0
On 6 January 2011 17:02, Ian Lance Taylor wrote:
> Oh yeah, you should never have a subreg of a subreg. That's a bug.
> Where did that come from?
Oh, that's interesting information! I have a splitter for movdf that
must be the culprit. I will tighten the split condition to disallow
splitting a s
I was playing with adding support of the various modes of widening
multiplies on my backend, and hit some restrictions in the expansion
code that I couldn't explain to myself. These restrictions only impact
the signed by unsigned version.
The first limitation was about the detection of widening mu
While working on having the divisions by constants optimized by my GCC
targeting, I realized that whatever *muldi3_highpart my backend
provides, it would never be used because of the bounds checks that
expmed.c does on the cost arrays. For example:
choose_multiplier (abs_d, size, size - 1,
On 27 March 2013 10:10, Richard Biener wrote:
> On Tue, Mar 26, 2013 at 6:55 PM, Frederic Riss
> wrote:
>> The cost arrays are filled up to
>> MAX_BITS_PER_WORD, thus as a temporary workaround I have defined
>> MAX_BITS_PER_WORD to 64, and I have softened the chec
On 27 March 2013 10:05, Richard Biener wrote:
> On Tue, Mar 26, 2013 at 6:30 PM, Frederic Riss
> wrote:
>> Here, the code trying to expand a signed by unsigned widening multiply
>> explicitly checks that the operand isn't a constant. Why is that? I
>> removed that
Hello,
I have coded SIMD support for my target, but I'm hitting some issues
relative to alignment. I can't find any documentation or comment
describing the assumptions that the vectorizer makes about target
support, if it exists please just point me at it (I'm based on GCC 4.7
for now).
On my tar
On 12 September 2013 11:25, Richard Biener wrote:
> You may simply hit some bug in the vectorizer. The vectorizer assumes
> it can re-align local decls, and for the above it should use
> known-misalignment
> accesses. You can check with -fdump-rtl-expand-details-alias what the
> MEMs think they
On 12 September 2013 12:47, Richard Biener wrote:
> Look at the -fdump-tree-vect-details, it should print what it does during
> alignment analysis. Then debug the code ...
OK, I think I got to the bottom of this. It's not the vectorizer fault
after all. Jakub was right to point out that there is
I try to convert my port to the new memory-model-aware atomic
builtins, but I'm facing some code generation issue because of the
__atomic_compare_exchange prototype (passing the comparison value by
reference). For example, for a simple wrapper around
__atomic_compare_exchange, the code at the end o
On 13 March 2012 22:36, Frédéric RISS wrote:
> In 4.7, the COND_EXPR has become a GIMPLE_TERNARY_RHS rhs_class, meaning
> that it won't use the expand_assigment path in expand_gimple_stmt_1, but
> will use straight expression expansion which will generate control flow
> RTL for the COND_EXPR.
>
>
On 14 March 2012 11:48, Richard Guenther wrote:
> On Wed, Mar 14, 2012 at 11:39 AM, Frederic Riss
> wrote:
>> Doing that at expansion time looks like papering over some other issue
>> though.
>
> Can you check where the COND_EXPR is introduced? That place should
>
On 2 October 2012 20:25, Frederic Riss wrote:
> Something must be wrong, as I don't see how reload can safely move
> memory expressions other than constant addresses around like this.
I dug a bit more, and I'm still confused about this reload behavior.
Let's take this pseud
Thanks to the help of segher and iant on IRC (thanks again!), I
narrowed my problem down to something I can fully understand and
explain (well I hope).
There is a bad interaction between the IRA handling of subregs and
reload's use of REG_EQUIV annotations. Each one seems to be in its
right to do
37 matches
Mail list logo
