Menu
▾
▴
gcc4cli-devel — Discussions on development issues of the project
You can subscribe to this list here.
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(17) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2010 |
Jan
(6) |
Feb
(4) |
Mar
(46) |
Apr
(2) |
May
|
Jun
(4) |
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
(21) |
Mar
(2) |
Apr
|
May
(19) |
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Thierry L. <thi...@in...> - 2010-03-22 11:11:44
|
I forgot to mention that (Mono) ilasm does not complains (not even a warning) if you pass it an unknown option; so this should be ok with older version of ilasm. Regarding "Pnet ilasm", I don't know, but I've been told that this option would be abandonned. If this is really the case, then we should also remove the "if [ `$ILASM --version | ..." test. Tell me: I can do it in this commit. Regards, Thierry Lafage. Thierry Lafage a écrit : > Hi, > > Here is a patch for our binutils/as script which converts -O option > into forthcoming '-opt:ldc' ilasm option. > > Since the default behavior is not changed, I should commit soon if > nobody complains. > > Regards, > Thierry Lafage. > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > ------------------------------------------------------------------------ > > _______________________________________________ > Gcc4cli-devel mailing list > Gcc...@li... > https://lists.sourceforge.net/lists/listinfo/gcc4cli-devel |
|
From: Thierry L. <thi...@in...> - 2010-03-22 11:07:26
|
Hi, Here is a patch for our binutils/as script which converts -O option into forthcoming '-opt:ldc' ilasm option. Since the default behavior is not changed, I should commit soon if nobody complains. Regards, Thierry Lafage. |
|
From: Thierry L. <thi...@in...> - 2010-03-22 11:05:12
|
Hi all, Here is a patch for binutils/ld which enables the possibility to specifiy the runtime version for ld (1.0 (default), 1.1 or 2.0). This is useful if you want to use eg. a trunk/head mono version (which does not contain 1.0 anymore) and still run the gcc tests (which fails when runtime warnings occur). Note that, by default, the behavior is not changed. If no one has comment on it, I should commit it soon. Regards, Thierry Lafage. Thierry Lafage a écrit : > Hi all, > > Here at IRISA, we are currently using the head of the svn trunk > version of Mono. In this version, .Net profile 1.0 support has been > removed. > If we use the binutils with this version of Mono, then it warns that > it cannot find the correct "runtime version". > > In CFile.cs, if we replace: > Assembly = AssemblyFactory.DefineAssembly (name, name, > > *TargetRuntime.NET_1_0*, > kind); > by > Assembly = AssemblyFactory.DefineAssembly (name, name, > > *TargetRuntime.NET_2_0*, > kind); > then it works fine. > > I don't know the consequences on other's code of such a change. To > minimize it, I propose to add a flag to the binutils command lines > like eg. -profile=2 and to let 1.0 be the default case. > > What do you think? > > Regards, > Thierry Lafage. > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > ------------------------------------------------------------------------ > > _______________________________________________ > Gcc4cli-devel mailing list > Gcc...@li... > https://lists.sourceforge.net/lists/listinfo/gcc4cli-devel > |
|
From: Thierry L. <thi...@in...> - 2010-03-19 11:20:01
|
Commited. Thierry Lafage. Thierry Lafage a écrit : > Hi all, > > Here is a new version of my previous patch on the simp-cond pass, > after previous duscussions on this list and discussions with Erven. > The idea, here, is to allow inversion of conditions on floats only if > a specific flag is set; this flag is set either individually or with > the -Os option (optimize for size) since the benefit of this inversion > would only be code size (and cleaner CIL code). > Inversion of conditions with integer arguments now include > brfalse/brtrue opcodes and is also activated by a specific flag, set > either individually or with -On (n >= 1) or -Os. > > Feel free to comment. > > If everebody agree, I should commit it in a few days. > > Have a good week-end, > > Thierry Lafage. > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > ------------------------------------------------------------------------ > > _______________________________________________ > Gcc4cli-devel mailing list > Gcc...@li... > https://lists.sourceforge.net/lists/listinfo/gcc4cli-devel |
|
From: Thierry L. <thi...@in...> - 2010-03-17 17:34:41
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> </head> <body bgcolor="#ffffff" text="#000000"> Hi all,<br> <br> Here at IRISA, we are currently using the head of the svn trunk version of Mono. In this version, .Net profile 1.0 support has been removed.<br> If we use the binutils with this version of Mono, then it warns that it cannot find the correct "runtime version".<br> <br> In CFile.cs, if we replace:<br> <font color="#660000"><tt> Assembly = AssemblyFactory.DefineAssembly (name, name,<br> <b>TargetRuntime.NET_1_0</b>,<br> kind);<br> </tt></font>by<br> <font color="#660000"><tt> Assembly = AssemblyFactory.DefineAssembly (name, name,<br> <b>TargetRuntime.NET_2_0</b>,<br> kind);<br> </tt></font>then it works fine.<br> <br> I don't know the consequences on other's code of such a change. To minimize it, I propose to add a flag to the binutils command lines like eg. -profile=2 and to let 1.0 be the default case.<br> <br> What do you think?<br> <br> Regards,<br> <pre class="moz-signature" cols="72">Thierry Lafage. </pre> </body> </html> |
|
From: Thierry L. <thi...@in...> - 2010-03-12 16:31:37
|
Hi all, Here is a new version of my previous patch on the simp-cond pass, after previous duscussions on this list and discussions with Erven. The idea, here, is to allow inversion of conditions on floats only if a specific flag is set; this flag is set either individually or with the -Os option (optimize for size) since the benefit of this inversion would only be code size (and cleaner CIL code). Inversion of conditions with integer arguments now include brfalse/brtrue opcodes and is also activated by a specific flag, set either individually or with -On (n >= 1) or -Os. Feel free to comment. If everebody agree, I should commit it in a few days. Have a good week-end, Thierry Lafage. |
|
From: Thierry L. <thi...@in...> - 2010-03-12 16:20:57
|
Hi all, This is just to says that patches pr19340.c.patch and gcc4cli_line_info-t-cil32.patch have been commited in our branch. Thierry Lafage. Thierry Lafage a écrit : > Hi all, > > Here are several small patches for our gcc4cli BE branch: > > * *pr19340.c.patch* is to avoid testing with pr19340.c because it > has no sense in cil32 since it tests the scheduler. > * *gcc4cli_line_info-t-cil32.patch* fixes dependencies in t-cil32 > and adds the file source-location.h which was introduced in my > last patch concerning source location (this t-cil32 patch should > have been part of the source location patch). > * *cil-lower.c.patch* modifies the pass gate in order to activate > this pass only when -ftree_vectorize option is activated (which > is the case in -O3) > * and *simp-cond.patch* is a simplification of the simp-cond pass > which also makes it more complete (adds support for > brtrue/brfalse and for floating point comparisons in conditional > branches + add a command-line option which is activated in -O1 + > fixes missing brtrue/brfalse as being conditional branch > instructions). Note that this pass either does nothing, or > change a branch condition instruction into another one (inverts > the condition) and removes the following unconditional branch. > This means that the stack is not changed at all, so I removed > all the stuff that was recomputing the stack at every statement. > Moreover, I didn't understand the test on the conditional branch > operand type (integer or pointer) in order to change the > conditional br instruction: I've removed it and tested on a real > program, and it seems to be ok. More tests are on the way > (check-gcc + cbenchmarks). > > Feel free to comment. I should commit in a few days if you're ok (or > if you don't say anything). > > Regards, > Thierry Lafage. > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > ------------------------------------------------------------------------ > > _______________________________________________ > Gcc4cli-devel mailing list > Gcc...@li... > https://lists.sourceforge.net/lists/listinfo/gcc4cli-devel |
|
From: Thierry L. <thi...@in...> - 2010-03-10 09:38:56
|
Hi Andrea,
Thanks for your remark. I'll make use of OPTIMIZATION_OPTIONS: it's a
macro which is called in opts.c (whereas OVERRIDE_OPTIONS is called from
toplev.c).
Thierry Lafage.
Andrea Carlo Ornstein a écrit :
> Hi,
> Sorry for the late replay.
>
> I have left only one remark (Gabriele and Erven already addressed all
> the others).
>
> We should probably avoid the changes in gcc/opts.c
> the right way of doing it is by defining OPTIMIZATION_OPTIONS in
> cil32.h as we did for OVERRIDE_OPTIONS
> You can look for an example on how to use them to gcc/config/cris/cris.[hc]
> it defines both OPTIMIZATION_OPTIONS and OVERRIDE_OPTIONS
>
> I do not remember exactly the difference of the two, so I do not know
> exactly where to put it, but the option does not exists for other
> targets.
>
> Andrea
>
>
>
>
> On Mon, Mar 8, 2010 at 5:39 PM, Thierry Lafage <thi...@in...> wrote:
>
>> Hi all,
>>
>> Here are several small patches for our gcc4cli BE branch:
>>
>> pr19340.c.patch is to avoid testing with pr19340.c because it has no sense
>> in cil32 since it tests the scheduler.
>> gcc4cli_line_info-t-cil32.patch fixes dependencies in t-cil32 and adds the
>> file source-location.h which was introduced in my last patch concerning
>> source location (this t-cil32 patch should have been part of the source
>> location patch).
>> cil-lower.c.patch modifies the pass gate in order to activate this pass only
>> when -ftree_vectorize option is activated (which is the case in -O3)
>> and simp-cond.patch is a simplification of the simp-cond pass which also
>> makes it more complete (adds support for brtrue/brfalse and for floating
>> point comparisons in conditional branches + add a command-line option which
>> is activated in -O1 + fixes missing brtrue/brfalse as being conditional
>> branch instructions). Note that this pass either does nothing, or change a
>> branch condition instruction into another one (inverts the condition) and
>> removes the following unconditional branch. This means that the stack is not
>> changed at all, so I removed all the stuff that was recomputing the stack at
>> every statement. Moreover, I didn't understand the test on the conditional
>> branch operand type (integer or pointer) in order to change the conditional
>> br instruction: I've removed it and tested on a real program, and it seems
>> to be ok. More tests are on the way (check-gcc + cbenchmarks).
>>
>> Feel free to comment. I should commit in a few days if you're ok (or if you
>> don't say anything).
>>
>> Regards,
>>
>> Thierry Lafage.
>>
>> Index: gcc/config/cil32/cil-lower.c
>> ===================================================================
>> --- gcc/config/cil32/cil-lower.c (revision 156016)
>> +++ gcc/config/cil32/cil-lower.c (working copy)
>> @@ -1,6 +1,6 @@
>> /* CIL IR lowering.
>>
>> - Copyright (C) 2009 Free Software Foundation, Inc.
>> + Copyright (C) 2009-2010 Free Software Foundation, Inc.
>>
>> This file is part of GCC.
>>
>> @@ -23,11 +23,13 @@
>> Andrea C. Ornstein
>> Erven Rohou
>> Gabriele Svelto
>> + Thierry Lafage
>>
>> Contact information at STMicroelectronics:
>> Andrea C. Ornstein <and...@st...>
>> Contact information at INRIA:
>> Erven Rohou <erv...@in...>
>> +Thierry Lafage <thi...@in...>
>> */
>>
>> #include <stdio.h>
>> @@ -52,6 +54,8 @@
>> * Globals
>> *
>> ******************************************************************************/
>>
>> +extern int flag_tree_vectorize; // TL // This avoids including options.h
>> +
>> enum simd_backend simd_type = UNDEF_SIMD;
>>
>> /******************************************************************************
>> @@ -591,8 +595,7 @@
>> static bool
>> lower_cil_gate (void)
>> {
>> - /* FIXME: should lower only if vector types are handled in this funtion.
>> */
>> - return true;
>> + return flag_tree_vectorize != 0;
>> }
>>
>>
>>
>> Index: gcc/config/cil32/t-cil32
>> ===================================================================
>> --- gcc/config/cil32/t-cil32 (revision 156016)
>> +++ gcc/config/cil32/t-cil32 (working copy)
>> @@ -110,6 +110,7 @@
>> $(srcdir)/config/cil32/cil-stmt.h \
>> $(srcdir)/config/cil32/cil-types.h \
>> $(srcdir)/config/cil32/emit-cil.h \
>> + $(srcdir)/config/cil32/source-location.h \
>> $(CONFIG_H) $(FLAGS_H) $(GGC_H) \
>> $(SYSTEM_H) $(TIMEVAR_H) $(TM_H) $(TREE_H) $(TREE_FLOW_H) $(TREE_PASS_H)
>> \
>> coretypes.h errors.h pointer-set.h
>> @@ -134,6 +135,7 @@
>> missing-protos.o : $(srcdir)/config/cil32/missing-protos.c \
>> $(srcdir)/config/cil32/cil-refs.h $(srcdir)/config/cil32/cil-stmt.h \
>> $(srcdir)/config/cil32/cil-stmt-inline.h
>> $(srcdir)/config/cil32/cil-stack.h \
>> + $(srcdir)/config/cil32/source-location.h \
>> $(srcdir)/config/cil32/cil-types.h $(CONFIG_H) $(FLAGS_H) $(SYSTEM_H) \
>> $(TIMEVAR_H) $(TM_H) $(TREE_H) $(TREE_PASS_H) coretypes.h errors.h \
>> pointer-set.h
>>
>> Index: gcc/testsuite/gcc.dg/pr19340.c
>> ===================================================================
>> --- gcc/testsuite/gcc.dg/pr19340.c (revision 156016)
>> +++ gcc/testsuite/gcc.dg/pr19340.c (working copy)
>> @@ -1,6 +1,6 @@
>> /* { dg-do compile } */
>> /* { dg-options "-O1 -fschedule-insns2 -fsched2-use-traces" } */
>> -/* { dg-skip-if "No scheduling" { mmix-*-* cris-*-* crisv32-*-* fido-*-*
>> m68k-*-* m32c-*-* avr-*-* } { "*" } { "" } } */
>> +/* { dg-skip-if "No scheduling" { mmix-*-* cris-*-* crisv32-*-* fido-*-*
>> m68k-*-* m32c-*-* avr-*-* cil32-*-* } { "*" } { "" } } */
>>
>> extern double f (double x);
>>
>>
>> Index: gcc/opts.c
>> ===================================================================
>> --- gcc/opts.c (revision 156016)
>> +++ gcc/opts.c (working copy)
>> @@ -914,6 +914,7 @@
>> flag_tree_copy_prop = opt1;
>> flag_tree_sink = opt1;
>> flag_tree_ch = opt1;
>> + flag_cil32_simp_cond = opt1;
>>
>> /* -O2 optimizations. */
>> opt2 = (optimize >= 2);
>> Index: gcc/config/cil32/cil32.opt
>> ===================================================================
>> --- gcc/config/cil32/cil32.opt (revision 156016)
>> +++ gcc/config/cil32/cil32.opt (working copy)
>> @@ -77,3 +77,7 @@
>> msimd=
>> Target Joined RejectNegative Var(simd_backend_str)
>> -msimd=gcc|mono Select the SIMD backend
>> +
>> +fcil32simpcond
>> +Target Report Var(flag_cil32_simp_cond) Optimization ; added to -O1
>> +Enable simplification of conditional expressions to make use of the fall
>> through path when possible
>> Index: gcc/config/cil32/simp-cond.c
>> ===================================================================
>> --- gcc/config/cil32/simp-cond.c (revision 156016)
>> +++ gcc/config/cil32/simp-cond.c (working copy)
>> @@ -2,7 +2,7 @@
>> conditional/unconditional branches if one of the two outgoing paths falls
>> through to the next basic block.
>>
>> - Copyright (C) 2006-2009 Free Software Foundation, Inc.
>> + Copyright (C) 2006-2010 Free Software Foundation, Inc.
>>
>> This file is part of GCC.
>>
>> @@ -25,11 +25,13 @@
>> Andrea Ornstein
>> Erven Rohou
>> Gabriele Svelto
>> + Thierry Lafage
>>
>> Contact information at STMicroelectronics:
>> Andrea C. Ornstein <and...@st...>
>> Contact information at INRIA:
>> Erven Rohou <erv...@in...>
>> +Thierry Lafage <thi...@in...>
>> */
>>
>> #include "config.h"
>> @@ -45,11 +47,13 @@
>> #include "cil-stmt.h"
>> #include "cil-types.h"
>>
>> +extern int flag_cil32_simp_cond;
>> +
>> /******************************************************************************
>> * Local functions prototypes
>> *
>> ******************************************************************************/
>>
>> -static void simplify_cond_branch (cil_stmt_iterator *, cil_stack);
>> +static void simplify_cond_branch (cil_stmt_iterator *);
>> static unsigned int simp_cond (void);
>> static bool simp_cond_gate (void);
>>
>> @@ -58,17 +62,18 @@
>> ******************************************************************************/
>>
>> static void
>> -simplify_cond_branch (cil_stmt_iterator *csi, cil_stack stack)
>> +simplify_cond_branch (cil_stmt_iterator *csi)
>> {
>> cil_stmt stmt;
>> - cil_type_t type;
>> enum cil_opcode opcode;
>> tree label_then, label_else;
>> - basic_block then_bb;
>> + basic_block cur_bb, then_bb;
>> edge true_edge, false_edge;
>>
>> + cur_bb = csi_bb (*csi);
>> +
>> /* Extract the condition's edges. */
>> - extract_true_false_edges_from_block (csi_bb (*csi), &true_edge,
>> &false_edge);
>> + extract_true_false_edges_from_block (cur_bb, &true_edge, &false_edge);
>> label_then = gimple_block_label (true_edge->dest);
>> label_else = gimple_block_label (false_edge->dest);
>>
>> @@ -76,37 +81,34 @@
>>
>> /* Simplify the condition only if the 'then' edge can be turned into a
>> fall through to the next basic block. */
>> - if (csi_bb (*csi)->next_bb == then_bb)
>> + if (cur_bb->next_bb == then_bb)
>> {
>> - type = cil_stack_top (stack);
>> -
>> - if (cil_integer_p (type) || cil_pointer_p (type))
>> + switch (cil_opcode (csi_stmt (*csi)))
>> {
>> - switch (cil_opcode (csi_stmt (*csi)))
>> - {
>> - case CIL_BEQ: opcode = CIL_BNE_UN; break;
>> - case CIL_BGE: opcode = CIL_BLT; break;
>> - case CIL_BGE_UN: opcode = CIL_BLT_UN; break;
>> - case CIL_BGT: opcode = CIL_BLE; break;
>> - case CIL_BGT_UN: opcode = CIL_BLE_UN; break;
>> - case CIL_BLE: opcode = CIL_BGT; break;
>> - case CIL_BLE_UN: opcode = CIL_BGT_UN; break;
>> - case CIL_BLT: opcode = CIL_BGE; break;
>> - case CIL_BLT_UN: opcode = CIL_BGE_UN; break;
>> - case CIL_BNE_UN: opcode = CIL_BEQ; break;
>> - default:
>> - return; /* Do nothing, we cannot change this branch. */
>> - }
>> + case CIL_BEQ: opcode = CIL_BNE_UN; break;
>> + case CIL_BGE: opcode = CIL_BLT; break;
>> + case CIL_BGE_UN: opcode = CIL_BLT_UN; break;
>> + case CIL_BGT: opcode = CIL_BLE; break;
>> + case CIL_BGT_UN: opcode = CIL_BLE_UN; break;
>> + case CIL_BLE: opcode = CIL_BGT; break;
>> + case CIL_BLE_UN: opcode = CIL_BGT_UN; break;
>> + case CIL_BLT: opcode = CIL_BGE; break;
>> + case CIL_BLT_UN: opcode = CIL_BGE_UN; break;
>> + case CIL_BNE_UN: opcode = CIL_BEQ; break;
>> + case CIL_BRTRUE: opcode = CIL_BRFALSE; break;
>> + case CIL_BRFALSE: opcode = CIL_BRTRUE; break;
>> + default:
>> + return; /* Do nothing, we cannot change this branch. */
>> + }
>>
>> - stmt = cil_build_stmt_arg (opcode, label_else);
>> - csi_replace (csi, stmt);
>> - csi_next (csi);
>> - csi_remove (csi);
>> + stmt = cil_build_stmt_arg (opcode, label_else);
>> + csi_replace (csi, stmt);
>> + csi_next (csi);
>> + csi_remove (csi);
>>
>> - /* Invert the out-going edges */
>> - true_edge->flags ^= (EDGE_TRUE_VALUE | EDGE_FALSE_VALUE);
>> - false_edge->flags ^= (EDGE_TRUE_VALUE | EDGE_FALSE_VALUE);
>> - }
>> + /* Invert the out-going edges */
>> + true_edge->flags ^= (EDGE_TRUE_VALUE | EDGE_FALSE_VALUE);
>> + false_edge->flags ^= (EDGE_TRUE_VALUE | EDGE_FALSE_VALUE);
>> }
>> }
>>
>> @@ -120,23 +122,14 @@
>> basic_block bb;
>> cil_stmt_iterator csi;
>> cil_stmt stmt;
>> - enum cil_opcode opcode;
>> - cil_bb_stacks bbs;
>> - cil_stack stack;
>> - edge_iterator ei;
>> - edge e;
>> -
>> - bbs = cil_bb_stacks_create ();
>>
>> FOR_EACH_BB (bb)
>> {
>> - stack = cil_stack_for_bb (bbs, bb);
>> csi = csi_start_bb (bb);
>>
>> while (!csi_end_p (csi))
>> {
>> stmt = csi_stmt (csi);
>> - opcode = cil_opcode (stmt);
>>
>> if (cil_cond_branch_p (stmt) && !csi_one_before_end_p (csi))
>> {
>> @@ -145,22 +138,15 @@
>> if (cil_opcode (csi_stmt (csi)) == CIL_BR)
>> {
>> csi_prev (&csi);
>> - simplify_cond_branch (&csi, stack);
>> + simplify_cond_branch (&csi);
>> break;
>> }
>> }
>>
>> - cil_stack_after_stmt (stack, stmt);
>> csi_next (&csi);
>> }
>> -
>> - FOR_EACH_EDGE (e, ei, bb->succs)
>> - {
>> - cil_set_stack_for_bb (bbs, e->dest, stack);
>> - }
>> }
>>
>> - cil_bb_stacks_destroy (bbs);
>> return 0;
>> }
>>
>> @@ -169,7 +155,7 @@
>> static bool
>> simp_cond_gate (void)
>> {
>> - return true;
>> + return flag_cil32_simp_cond != 0;
>> }
>>
>> /* Define the parameters of the cond-simp pass. */
>> Index: gcc/config/cil32/cil-stmt.c
>> ===================================================================
>> --- gcc/config/cil32/cil-stmt.c (revision 156016)
>> +++ gcc/config/cil32/cil-stmt.c (working copy)
>> @@ -1,6 +1,6 @@
>> /* CIL statements, sequences and iterators implementation.
>>
>> - Copyright (C) 2006-2009 Free Software Foundation, Inc.
>> + Copyright (C) 2006-2010 Free Software Foundation, Inc.
>>
>> This file is part of GCC.
>>
>> @@ -23,11 +23,13 @@
>> Andrea Ornstein
>> Erven Rohou
>> Gabriele Svelto
>> + Thierry Lafage
>>
>> Contact information at STMicroelectronics:
>> Andrea C. Ornstein <and...@st...>
>> Contact information at INRIA:
>> Erven Rohou <erv...@in...>
>> +Thierry Lafage <thi...@in...>
>> */
>>
>> #include "config.h"
>> @@ -502,7 +504,9 @@
>> case CIL_BLT:
>> case CIL_BLT_UN:
>> case CIL_BNE_UN:
>> - return true;
>> + case CIL_BRFALSE:
>> + case CIL_BRTRUE:
>> + return true;
>>
>> default:
>> return false;
>>
>> ------------------------------------------------------------------------------
>> Download Intel® Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Gcc4cli-devel mailing list
>> Gcc...@li...
>> https://lists.sourceforge.net/lists/listinfo/gcc4cli-devel
>>
>>
>>
|
|
From: Thierry L. <thi...@in...> - 2010-03-10 09:37:52
|
Hi Gabriele, > Hi Thierry, > >> For true/false, it happens that conditions on floating point values may be >> computed by first using a comparison, and then a brtrue or brfalse. So >> inverting the branch may lead to the same problems as with branches with FP >> operands. >> > > OK, that must be why I've left it out. > In fact, I've reverted my changes, and added cases to invert brtrue and brfalse because I still think it could work. Indeed, brtrue is the exact negation of brfalse whether a previous comparison occured on floats or not. I ran the testsuite, and it passed as well as before any change: 1247 unexpected fails, but all ieee tests that did not pass after my 1st patch now pass. So I think it's ok. >> For the FP general case, wouldn't it be possible to use *.un (or not) >> versions of the branches? I'll make tests to check. >> > > Yes, if you are very careful you can change some of the conditions by > using the appropriate unordered comparisons. However you should also > verify with the mono JIT compiler if it is worth to do it: many > architectures do not have the full range of floating-point > ordered/unordered comparisons so on those architectures using them > will result in very poor native code at JIT time. After considering > all the problems I decided not to touch them because the chance of > introducing some serious regressions was fairly high and the gain was > very little. > Despite it could result in poorer native code (when generating bytecode, we are not supposed to know the final target machine), inverting conditions in conditional branches still allows to reduce bytecode size (and, for some targets, it should speed up a little), so if I can do something for float comparisons, perhaps it would be worth adding another flag which would be activated with -Os, wouldn't it? I'll make some tests, then discuss with Erven (when he's cured), and finally come back to you with another, cleaner, patch. Regards, Thierry. |
|
From: Andrea C. O. <and...@gm...> - 2010-03-09 18:44:13
|
We lost the implementation when we moved to the new IR if you recall, we did not want to wait for the new IR to have all this part completed. It was on the TODO list to add it back but we never got the time. I guess the same apply to abs. Andrea On Fri, Feb 19, 2010 at 4:10 PM, Erven Rohou <erv...@in...> wrote: > Hello, > > We used to have a flag -mexpand-minmax. > Actually, the flag is still here, but it does nothing. I checked 'svn log', but > I could not find much. > Does anybody remember what happened? We always emit a call to min or max? > > -- > Erven. > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Gcc4cli-devel mailing list > Gcc...@li... > https://lists.sourceforge.net/lists/listinfo/gcc4cli-devel > |
|
From: Andrea C. O. <and...@gm...> - 2010-03-09 18:10:33
|
Hi,
Sorry for the late replay.
I have left only one remark (Gabriele and Erven already addressed all
the others).
We should probably avoid the changes in gcc/opts.c
the right way of doing it is by defining OPTIMIZATION_OPTIONS in
cil32.h as we did for OVERRIDE_OPTIONS
You can look for an example on how to use them to gcc/config/cris/cris.[hc]
it defines both OPTIMIZATION_OPTIONS and OVERRIDE_OPTIONS
I do not remember exactly the difference of the two, so I do not know
exactly where to put it, but the option does not exists for other
targets.
Andrea
On Mon, Mar 8, 2010 at 5:39 PM, Thierry Lafage <thi...@in...> wrote:
> Hi all,
>
> Here are several small patches for our gcc4cli BE branch:
>
> pr19340.c.patch is to avoid testing with pr19340.c because it has no sense
> in cil32 since it tests the scheduler.
> gcc4cli_line_info-t-cil32.patch fixes dependencies in t-cil32 and adds the
> file source-location.h which was introduced in my last patch concerning
> source location (this t-cil32 patch should have been part of the source
> location patch).
> cil-lower.c.patch modifies the pass gate in order to activate this pass only
> when -ftree_vectorize option is activated (which is the case in -O3)
> and simp-cond.patch is a simplification of the simp-cond pass which also
> makes it more complete (adds support for brtrue/brfalse and for floating
> point comparisons in conditional branches + add a command-line option which
> is activated in -O1 + fixes missing brtrue/brfalse as being conditional
> branch instructions). Note that this pass either does nothing, or change a
> branch condition instruction into another one (inverts the condition) and
> removes the following unconditional branch. This means that the stack is not
> changed at all, so I removed all the stuff that was recomputing the stack at
> every statement. Moreover, I didn't understand the test on the conditional
> branch operand type (integer or pointer) in order to change the conditional
> br instruction: I've removed it and tested on a real program, and it seems
> to be ok. More tests are on the way (check-gcc + cbenchmarks).
>
> Feel free to comment. I should commit in a few days if you're ok (or if you
> don't say anything).
>
> Regards,
>
> Thierry Lafage.
>
> Index: gcc/config/cil32/cil-lower.c
> ===================================================================
> --- gcc/config/cil32/cil-lower.c (revision 156016)
> +++ gcc/config/cil32/cil-lower.c (working copy)
> @@ -1,6 +1,6 @@
> /* CIL IR lowering.
>
> - Copyright (C) 2009 Free Software Foundation, Inc.
> + Copyright (C) 2009-2010 Free Software Foundation, Inc.
>
> This file is part of GCC.
>
> @@ -23,11 +23,13 @@
> Andrea C. Ornstein
> Erven Rohou
> Gabriele Svelto
> + Thierry Lafage
>
> Contact information at STMicroelectronics:
> Andrea C. Ornstein <and...@st...>
> Contact information at INRIA:
> Erven Rohou <erv...@in...>
> +Thierry Lafage <thi...@in...>
> */
>
> #include <stdio.h>
> @@ -52,6 +54,8 @@
> * Globals
> *
> ******************************************************************************/
>
> +extern int flag_tree_vectorize; // TL // This avoids including options.h
> +
> enum simd_backend simd_type = UNDEF_SIMD;
>
> /******************************************************************************
> @@ -591,8 +595,7 @@
> static bool
> lower_cil_gate (void)
> {
> - /* FIXME: should lower only if vector types are handled in this funtion.
> */
> - return true;
> + return flag_tree_vectorize != 0;
> }
>
>
>
> Index: gcc/config/cil32/t-cil32
> ===================================================================
> --- gcc/config/cil32/t-cil32 (revision 156016)
> +++ gcc/config/cil32/t-cil32 (working copy)
> @@ -110,6 +110,7 @@
> $(srcdir)/config/cil32/cil-stmt.h \
> $(srcdir)/config/cil32/cil-types.h \
> $(srcdir)/config/cil32/emit-cil.h \
> + $(srcdir)/config/cil32/source-location.h \
> $(CONFIG_H) $(FLAGS_H) $(GGC_H) \
> $(SYSTEM_H) $(TIMEVAR_H) $(TM_H) $(TREE_H) $(TREE_FLOW_H) $(TREE_PASS_H)
> \
> coretypes.h errors.h pointer-set.h
> @@ -134,6 +135,7 @@
> missing-protos.o : $(srcdir)/config/cil32/missing-protos.c \
> $(srcdir)/config/cil32/cil-refs.h $(srcdir)/config/cil32/cil-stmt.h \
> $(srcdir)/config/cil32/cil-stmt-inline.h
> $(srcdir)/config/cil32/cil-stack.h \
> + $(srcdir)/config/cil32/source-location.h \
> $(srcdir)/config/cil32/cil-types.h $(CONFIG_H) $(FLAGS_H) $(SYSTEM_H) \
> $(TIMEVAR_H) $(TM_H) $(TREE_H) $(TREE_PASS_H) coretypes.h errors.h \
> pointer-set.h
>
> Index: gcc/testsuite/gcc.dg/pr19340.c
> ===================================================================
> --- gcc/testsuite/gcc.dg/pr19340.c (revision 156016)
> +++ gcc/testsuite/gcc.dg/pr19340.c (working copy)
> @@ -1,6 +1,6 @@
> /* { dg-do compile } */
> /* { dg-options "-O1 -fschedule-insns2 -fsched2-use-traces" } */
> -/* { dg-skip-if "No scheduling" { mmix-*-* cris-*-* crisv32-*-* fido-*-*
> m68k-*-* m32c-*-* avr-*-* } { "*" } { "" } } */
> +/* { dg-skip-if "No scheduling" { mmix-*-* cris-*-* crisv32-*-* fido-*-*
> m68k-*-* m32c-*-* avr-*-* cil32-*-* } { "*" } { "" } } */
>
> extern double f (double x);
>
>
> Index: gcc/opts.c
> ===================================================================
> --- gcc/opts.c (revision 156016)
> +++ gcc/opts.c (working copy)
> @@ -914,6 +914,7 @@
> flag_tree_copy_prop = opt1;
> flag_tree_sink = opt1;
> flag_tree_ch = opt1;
> + flag_cil32_simp_cond = opt1;
>
> /* -O2 optimizations. */
> opt2 = (optimize >= 2);
> Index: gcc/config/cil32/cil32.opt
> ===================================================================
> --- gcc/config/cil32/cil32.opt (revision 156016)
> +++ gcc/config/cil32/cil32.opt (working copy)
> @@ -77,3 +77,7 @@
> msimd=
> Target Joined RejectNegative Var(simd_backend_str)
> -msimd=gcc|mono Select the SIMD backend
> +
> +fcil32simpcond
> +Target Report Var(flag_cil32_simp_cond) Optimization ; added to -O1
> +Enable simplification of conditional expressions to make use of the fall
> through path when possible
> Index: gcc/config/cil32/simp-cond.c
> ===================================================================
> --- gcc/config/cil32/simp-cond.c (revision 156016)
> +++ gcc/config/cil32/simp-cond.c (working copy)
> @@ -2,7 +2,7 @@
> conditional/unconditional branches if one of the two outgoing paths falls
> through to the next basic block.
>
> - Copyright (C) 2006-2009 Free Software Foundation, Inc.
> + Copyright (C) 2006-2010 Free Software Foundation, Inc.
>
> This file is part of GCC.
>
> @@ -25,11 +25,13 @@
> Andrea Ornstein
> Erven Rohou
> Gabriele Svelto
> + Thierry Lafage
>
> Contact information at STMicroelectronics:
> Andrea C. Ornstein <and...@st...>
> Contact information at INRIA:
> Erven Rohou <erv...@in...>
> +Thierry Lafage <thi...@in...>
> */
>
> #include "config.h"
> @@ -45,11 +47,13 @@
> #include "cil-stmt.h"
> #include "cil-types.h"
>
> +extern int flag_cil32_simp_cond;
> +
> /******************************************************************************
> * Local functions prototypes
> *
> ******************************************************************************/
>
> -static void simplify_cond_branch (cil_stmt_iterator *, cil_stack);
> +static void simplify_cond_branch (cil_stmt_iterator *);
> static unsigned int simp_cond (void);
> static bool simp_cond_gate (void);
>
> @@ -58,17 +62,18 @@
> ******************************************************************************/
>
> static void
> -simplify_cond_branch (cil_stmt_iterator *csi, cil_stack stack)
> +simplify_cond_branch (cil_stmt_iterator *csi)
> {
> cil_stmt stmt;
> - cil_type_t type;
> enum cil_opcode opcode;
> tree label_then, label_else;
> - basic_block then_bb;
> + basic_block cur_bb, then_bb;
> edge true_edge, false_edge;
>
> + cur_bb = csi_bb (*csi);
> +
> /* Extract the condition's edges. */
> - extract_true_false_edges_from_block (csi_bb (*csi), &true_edge,
> &false_edge);
> + extract_true_false_edges_from_block (cur_bb, &true_edge, &false_edge);
> label_then = gimple_block_label (true_edge->dest);
> label_else = gimple_block_label (false_edge->dest);
>
> @@ -76,37 +81,34 @@
>
> /* Simplify the condition only if the 'then' edge can be turned into a
> fall through to the next basic block. */
> - if (csi_bb (*csi)->next_bb == then_bb)
> + if (cur_bb->next_bb == then_bb)
> {
> - type = cil_stack_top (stack);
> -
> - if (cil_integer_p (type) || cil_pointer_p (type))
> + switch (cil_opcode (csi_stmt (*csi)))
> {
> - switch (cil_opcode (csi_stmt (*csi)))
> - {
> - case CIL_BEQ: opcode = CIL_BNE_UN; break;
> - case CIL_BGE: opcode = CIL_BLT; break;
> - case CIL_BGE_UN: opcode = CIL_BLT_UN; break;
> - case CIL_BGT: opcode = CIL_BLE; break;
> - case CIL_BGT_UN: opcode = CIL_BLE_UN; break;
> - case CIL_BLE: opcode = CIL_BGT; break;
> - case CIL_BLE_UN: opcode = CIL_BGT_UN; break;
> - case CIL_BLT: opcode = CIL_BGE; break;
> - case CIL_BLT_UN: opcode = CIL_BGE_UN; break;
> - case CIL_BNE_UN: opcode = CIL_BEQ; break;
> - default:
> - return; /* Do nothing, we cannot change this branch. */
> - }
> + case CIL_BEQ: opcode = CIL_BNE_UN; break;
> + case CIL_BGE: opcode = CIL_BLT; break;
> + case CIL_BGE_UN: opcode = CIL_BLT_UN; break;
> + case CIL_BGT: opcode = CIL_BLE; break;
> + case CIL_BGT_UN: opcode = CIL_BLE_UN; break;
> + case CIL_BLE: opcode = CIL_BGT; break;
> + case CIL_BLE_UN: opcode = CIL_BGT_UN; break;
> + case CIL_BLT: opcode = CIL_BGE; break;
> + case CIL_BLT_UN: opcode = CIL_BGE_UN; break;
> + case CIL_BNE_UN: opcode = CIL_BEQ; break;
> + case CIL_BRTRUE: opcode = CIL_BRFALSE; break;
> + case CIL_BRFALSE: opcode = CIL_BRTRUE; break;
> + default:
> + return; /* Do nothing, we cannot change this branch. */
> + }
>
> - stmt = cil_build_stmt_arg (opcode, label_else);
> - csi_replace (csi, stmt);
> - csi_next (csi);
> - csi_remove (csi);
> + stmt = cil_build_stmt_arg (opcode, label_else);
> + csi_replace (csi, stmt);
> + csi_next (csi);
> + csi_remove (csi);
>
> - /* Invert the out-going edges */
> - true_edge->flags ^= (EDGE_TRUE_VALUE | EDGE_FALSE_VALUE);
> - false_edge->flags ^= (EDGE_TRUE_VALUE | EDGE_FALSE_VALUE);
> - }
> + /* Invert the out-going edges */
> + true_edge->flags ^= (EDGE_TRUE_VALUE | EDGE_FALSE_VALUE);
> + false_edge->flags ^= (EDGE_TRUE_VALUE | EDGE_FALSE_VALUE);
> }
> }
>
> @@ -120,23 +122,14 @@
> basic_block bb;
> cil_stmt_iterator csi;
> cil_stmt stmt;
> - enum cil_opcode opcode;
> - cil_bb_stacks bbs;
> - cil_stack stack;
> - edge_iterator ei;
> - edge e;
> -
> - bbs = cil_bb_stacks_create ();
>
> FOR_EACH_BB (bb)
> {
> - stack = cil_stack_for_bb (bbs, bb);
> csi = csi_start_bb (bb);
>
> while (!csi_end_p (csi))
> {
> stmt = csi_stmt (csi);
> - opcode = cil_opcode (stmt);
>
> if (cil_cond_branch_p (stmt) && !csi_one_before_end_p (csi))
> {
> @@ -145,22 +138,15 @@
> if (cil_opcode (csi_stmt (csi)) == CIL_BR)
> {
> csi_prev (&csi);
> - simplify_cond_branch (&csi, stack);
> + simplify_cond_branch (&csi);
> break;
> }
> }
>
> - cil_stack_after_stmt (stack, stmt);
> csi_next (&csi);
> }
> -
> - FOR_EACH_EDGE (e, ei, bb->succs)
> - {
> - cil_set_stack_for_bb (bbs, e->dest, stack);
> - }
> }
>
> - cil_bb_stacks_destroy (bbs);
> return 0;
> }
>
> @@ -169,7 +155,7 @@
> static bool
> simp_cond_gate (void)
> {
> - return true;
> + return flag_cil32_simp_cond != 0;
> }
>
> /* Define the parameters of the cond-simp pass. */
> Index: gcc/config/cil32/cil-stmt.c
> ===================================================================
> --- gcc/config/cil32/cil-stmt.c (revision 156016)
> +++ gcc/config/cil32/cil-stmt.c (working copy)
> @@ -1,6 +1,6 @@
> /* CIL statements, sequences and iterators implementation.
>
> - Copyright (C) 2006-2009 Free Software Foundation, Inc.
> + Copyright (C) 2006-2010 Free Software Foundation, Inc.
>
> This file is part of GCC.
>
> @@ -23,11 +23,13 @@
> Andrea Ornstein
> Erven Rohou
> Gabriele Svelto
> + Thierry Lafage
>
> Contact information at STMicroelectronics:
> Andrea C. Ornstein <and...@st...>
> Contact information at INRIA:
> Erven Rohou <erv...@in...>
> +Thierry Lafage <thi...@in...>
> */
>
> #include "config.h"
> @@ -502,7 +504,9 @@
> case CIL_BLT:
> case CIL_BLT_UN:
> case CIL_BNE_UN:
> - return true;
> + case CIL_BRFALSE:
> + case CIL_BRTRUE:
> + return true;
>
> default:
> return false;
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Gcc4cli-devel mailing list
> Gcc...@li...
> https://lists.sourceforge.net/lists/listinfo/gcc4cli-devel
>
>
|
|
From: Erven R. <erv...@in...> - 2010-03-09 10:53:52
|
Thierry Lafage a écrit :
> Hi Gabriele,
>
> Thanks for your quick answer. My remarks below...
>
> Gabriele Svelto a écrit :
>> Hi Thierry.
>>
>> 2010/3/8 Thierry Lafage <thi...@in...>:
>>
>>> cil-lower.c.patch modifies the pass gate in order to activate this pass only
>>> when -ftree_vectorize option is activated (which is the case in -O3)
>>>
>> Unfortunately you cannot do this as the users can explicitly use
>> vector intrinsics in the code even if -O3 is not specified. Under
>> those conditions you will find vector operations even if you are
>> compiling with -O0, it happens quite often in the testsuite BTW.
>>
> Ok, sorry, I misunderstood the fixme "should lower only if vector types
> are handled in this funtion."
> I simply wanted, for easier debug, to ensure that the execution of this
> pass could be controlled (ie. skipped by using a command-line argument).
> But it's probably useless.
I made an attempt along those lines some time ago. My approach was to detect
whether a function "deals with" vectors, for some definition of "deals with".
You can grep "has_vec". The idea was to run the pass only is has_vec is true.
Unfortunately I was missing some cases. It is still not working.
--
Erven.
>
>>> and simp-cond.patch is a simplification of the simp-cond pass which also
>>> makes it more complete (adds support for brtrue/brfalse and for floating
>>> point comparisons in conditional branches + add a command-line option which
>>> is activated in -O1 + fixes missing brtrue/brfalse as being conditional
>>> branch instructions). Note that this pass either does nothing, or change a
>>> branch condition instruction into another one (inverts the condition) and
>>> removes the following unconditional branch. This means that the stack is not
>>> changed at all, so I removed all the stuff that was recomputing the stack at
>>> every statement. Moreover, I didn't understand the test on the conditional
>>> branch operand type (integer or pointer) in order to change the conditional
>>> br instruction: I've removed it and tested on a real program, and it seems
>>> to be ok.
>>>
>> You cannot remove the integer / pointer test from that pass because
>> for floating-point numbers those operations cannot be changed. For
>> example if 'x' and 'y' are two floating-point NaNs the result from any
>> comparison will always be unordered, i.e. x > y and x <= y will both
>> evaluate to false hence you cannot invert the comparison. That's why I
>> left out floating-point comparisons and that's why I compute the
>> stack: I need to know on what types the comparison is working on. As
>> for brtrue and brfalse I don't remember why I have left them out. They
>> are different from the other instructions in that they pop off the
>> stack a single value and work only on native integers while other
>> comparisons pop two values which can be pretty much anything. I might
>> have left them out because of that but I don't remember exactly so you
>> might give them a try anyway. A full testsuite will give you the
>> answer anyway, if there are problems tied to swapping brtrue/brfalse
>> they will probably manifest themselves there.
>>
>> Gabriele
>>
>
> Ok, for this one, I've been very naive. Sorry. It seems to me that it
> has been a fast copy/paste of a generic pass...
> For true/false, it happens that conditions on floating point values may
> be computed by first using a comparison, and then a brtrue or brfalse.
> So inverting the branch may lead to the same problems as with branches
> with FP operands. In this particular case, we could look up at the
> operands of the compare (if any) and invert the branch (or better: the
> compare itself?) only if they are integer or pointers.
> For the FP general case, wouldn't it be possible to use *.un (or not)
> versions of the branches? I'll make tests to check.
> However, concerning stack computation, since conditional branch
> inversion does not change the stack at all, are the
> "cil_stack_after_stmt (stack, stmt);" and "FOR_EACH_EDGE(...) {
> cil_set_stack_for_bb (...); }" useful?
> I understand these statements as being a stack re-compute, isn't it?
>
> Regards,
> Thierry.
>
>
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Gcc4cli-devel mailing list
> Gcc...@li...
> https://lists.sourceforge.net/lists/listinfo/gcc4cli-devel
|
|
From: Gabriele S. <gab...@gm...> - 2010-03-09 10:53:33
|
Hi Thierry,
2010/3/9 Thierry Lafage <thi...@in...>:
> Hi Gabriele,
>
> Ok, sorry, I misunderstood the fixme "should lower only if vector types are
> handled in this funtion."
> I simply wanted, for easier debug, to ensure that the execution of this pass
> could be controlled (ie. skipped by using a command-line argument). But it's
> probably useless.
such a flag might be useful but you should talk to Erven about it, he
was the one who wrote the pass IIRC.
> Ok, for this one, I've been very naive. Sorry. It seems to me that it has
> been a fast copy/paste of a generic pass...
I know, it certainly looked like it, in fact it was a rewrite of a
pass we did on the tree representation before we introduced the CIL
representation in the back-end.
> For true/false, it happens that conditions on floating point values may be
> computed by first using a comparison, and then a brtrue or brfalse. So
> inverting the branch may lead to the same problems as with branches with FP
> operands.
OK, that must be why I've left it out.
> In this particular case, we could look up at the operands of the
> compare (if any) and invert the branch (or better: the compare itself?) only
> if they are integer or pointers.
Yes, it might work. Anyway the GCC testsuite will show you if there
are any problems with this approach, I know it's very long and boring
to run it but it's the best way to spot hard-to-find errors. I believe
I tried switching the floating-point comparisons in the first place
and switched back to integers only after checking with the testsuite
myself.
> For the FP general case, wouldn't it be possible to use *.un (or not)
> versions of the branches? I'll make tests to check.
Yes, if you are very careful you can change some of the conditions by
using the appropriate unordered comparisons. However you should also
verify with the mono JIT compiler if it is worth to do it: many
architectures do not have the full range of floating-point
ordered/unordered comparisons so on those architectures using them
will result in very poor native code at JIT time. After considering
all the problems I decided not to touch them because the chance of
introducing some serious regressions was fairly high and the gain was
very little.
> However, concerning stack computation, since conditional branch inversion
> does not change the stack at all, are the "cil_stack_after_stmt (stack,
> stmt);" and "FOR_EACH_EDGE(...) { cil_set_stack_for_bb (...); }" useful?
> I understand these statements as being a stack re-compute, isn't it?
Yes, those compute the effect of an operation on the stack and
propagate them to target basic-blocks at the end of the loop. We need
them in order to know what are the types of the stack operands,
however they are very cheap operations, I specifically designed them
so that we don't need to fully recalculate the stack at every point.
Instead cil_stack_after_stmt() will update the provided stack with
only the changes caused by the specified instruction providing you
with an up-to-date state of the stack.
Gabriele
|
|
From: Thierry L. <thi...@in...> - 2010-03-09 10:38:15
|
Hi Gabriele,
Thanks for your quick answer. My remarks below...
Gabriele Svelto a écrit :
> Hi Thierry.
>
> 2010/3/8 Thierry Lafage <thi...@in...>:
>
>> cil-lower.c.patch modifies the pass gate in order to activate this pass only
>> when -ftree_vectorize option is activated (which is the case in -O3)
>>
> Unfortunately you cannot do this as the users can explicitly use
> vector intrinsics in the code even if -O3 is not specified. Under
> those conditions you will find vector operations even if you are
> compiling with -O0, it happens quite often in the testsuite BTW.
>
Ok, sorry, I misunderstood the fixme "should lower only if vector types
are handled in this funtion."
I simply wanted, for easier debug, to ensure that the execution of this
pass could be controlled (ie. skipped by using a command-line argument).
But it's probably useless.
>> and simp-cond.patch is a simplification of the simp-cond pass which also
>> makes it more complete (adds support for brtrue/brfalse and for floating
>> point comparisons in conditional branches + add a command-line option which
>> is activated in -O1 + fixes missing brtrue/brfalse as being conditional
>> branch instructions). Note that this pass either does nothing, or change a
>> branch condition instruction into another one (inverts the condition) and
>> removes the following unconditional branch. This means that the stack is not
>> changed at all, so I removed all the stuff that was recomputing the stack at
>> every statement. Moreover, I didn't understand the test on the conditional
>> branch operand type (integer or pointer) in order to change the conditional
>> br instruction: I've removed it and tested on a real program, and it seems
>> to be ok.
>>
>
> You cannot remove the integer / pointer test from that pass because
> for floating-point numbers those operations cannot be changed. For
> example if 'x' and 'y' are two floating-point NaNs the result from any
> comparison will always be unordered, i.e. x > y and x <= y will both
> evaluate to false hence you cannot invert the comparison. That's why I
> left out floating-point comparisons and that's why I compute the
> stack: I need to know on what types the comparison is working on. As
> for brtrue and brfalse I don't remember why I have left them out. They
> are different from the other instructions in that they pop off the
> stack a single value and work only on native integers while other
> comparisons pop two values which can be pretty much anything. I might
> have left them out because of that but I don't remember exactly so you
> might give them a try anyway. A full testsuite will give you the
> answer anyway, if there are problems tied to swapping brtrue/brfalse
> they will probably manifest themselves there.
>
> Gabriele
>
Ok, for this one, I've been very naive. Sorry. It seems to me that it
has been a fast copy/paste of a generic pass...
For true/false, it happens that conditions on floating point values may
be computed by first using a comparison, and then a brtrue or brfalse.
So inverting the branch may lead to the same problems as with branches
with FP operands. In this particular case, we could look up at the
operands of the compare (if any) and invert the branch (or better: the
compare itself?) only if they are integer or pointers.
For the FP general case, wouldn't it be possible to use *.un (or not)
versions of the branches? I'll make tests to check.
However, concerning stack computation, since conditional branch
inversion does not change the stack at all, are the
"cil_stack_after_stmt (stack, stmt);" and "FOR_EACH_EDGE(...) {
cil_set_stack_for_bb (...); }" useful?
I understand these statements as being a stack re-compute, isn't it?
Regards,
Thierry.
|
|
From: Gabriele S. <gab...@gm...> - 2010-03-08 20:12:43
|
Hi Erven,
2010/3/8 Erven Rohou <erv...@in...>:
> Hello everybody,
>
> I understand that we assume 32-bit pointers.
> But about endianness: I remember that we generate initializers for both, and a
> small run-time check to pick the right one. What are the cases where we have
> problems?
One (composed) word: bit-fields. And unfortunately not only the
bit-fields which you can find in regular C/C++ but also the ones that
GCC happily generates under many conditions. Here's one example:
struct foo
{
short a;
short b;
}
bool bar(struct foo*f)
{
if (foo->a == 1 && foo->b == 2)
return 1;
else
return 0;
}
GCC will turn the comparison into a BIT_FIELD_REF (or whatever it's
called now, there have been some changes there) that loads both the
16-bit integers as a single 32-bit integer and compares it with a
specifically tailored integer value. Unfortunately that value will be
different depending on the target endianness. When I was working on
that part of the project I tried disabling that specific optimization
only to find out that it was done both during the gimplification pass
and in the front-end (!) so it was impossible to remove it. I believe
that there were plans to move those optimizations in a better place
but I haven't followed the mailing-lists recently so I have no idea if
they actually did it. If they didn't, it is impossible to work around
that problem and that taints our code with the endian type we have
chosen at GCC build-time.
Gabriele
|
|
From: Gabriele S. <gab...@gm...> - 2010-03-08 19:57:25
|
Hi Thierry. 2010/3/8 Thierry Lafage <thi...@in...>: > Hi all, > > Here are several small patches for our gcc4cli BE branch: > > pr19340.c.patch is to avoid testing with pr19340.c because it has no sense > in cil32 since it tests the scheduler. > gcc4cli_line_info-t-cil32.patch fixes dependencies in t-cil32 and adds the > file source-location.h which was introduced in my last patch concerning > source location (this t-cil32 patch should have been part of the source > location patch). > cil-lower.c.patch modifies the pass gate in order to activate this pass only > when -ftree_vectorize option is activated (which is the case in -O3) Unfortunately you cannot do this as the users can explicitly use vector intrinsics in the code even if -O3 is not specified. Under those conditions you will find vector operations even if you are compiling with -O0, it happens quite often in the testsuite BTW. > and simp-cond.patch is a simplification of the simp-cond pass which also > makes it more complete (adds support for brtrue/brfalse and for floating > point comparisons in conditional branches + add a command-line option which > is activated in -O1 + fixes missing brtrue/brfalse as being conditional > branch instructions). Note that this pass either does nothing, or change a > branch condition instruction into another one (inverts the condition) and > removes the following unconditional branch. This means that the stack is not > changed at all, so I removed all the stuff that was recomputing the stack at > every statement. Moreover, I didn't understand the test on the conditional > branch operand type (integer or pointer) in order to change the conditional > br instruction: I've removed it and tested on a real program, and it seems > to be ok. You cannot remove the integer / pointer test from that pass because for floating-point numbers those operations cannot be changed. For example if 'x' and 'y' are two floating-point NaNs the result from any comparison will always be unordered, i.e. x > y and x <= y will both evaluate to false hence you cannot invert the comparison. That's why I left out floating-point comparisons and that's why I compute the stack: I need to know on what types the comparison is working on. As for brtrue and brfalse I don't remember why I have left them out. They are different from the other instructions in that they pop off the stack a single value and work only on native integers while other comparisons pop two values which can be pretty much anything. I might have left them out because of that but I don't remember exactly so you might give them a try anyway. A full testsuite will give you the answer anyway, if there are problems tied to swapping brtrue/brfalse they will probably manifest themselves there. Gabriele |
|
From: Erven R. <erv...@in...> - 2010-03-08 17:31:34
|
Hello everybody, I understand that we assume 32-bit pointers. But about endianness: I remember that we generate initializers for both, and a small run-time check to pick the right one. What are the cases where we have problems? -- Erven. Andrea Carlo Ornstein a écrit : > Hi, > > the libraries are in pure CLI and are portable in compatible machine > families (same pointer size, same endianness). > by default we compile little endian, 32bit pointer size > the 64bit pointer size was in the plans but we never got the time to > actually do it. > > Now, looking at the errors you report. > The first one, I guess was already reported from Erven and it's > probably an error in Mono > if I recall it correctly it mishandled a CLI copy object instruction > when passed an unmanaged pointer (it happens in initialization of > global variables) > > The second problem you have is in the assembler. > you can compile with -S and see how the assembly file looks like, it > should be the same on x86 and on sparc. > If so the error is in the as tool you are using that is ilasm (from Mono again). > > Andrea > > > On Wed, Mar 3, 2010 at 11:29 AM, Thierry Lafage <thi...@in...> wrote: >> Hi all, >> >> I'm currently in trouble to run a gcc4cli compiled CLI code (compiled on >> Linux/x86 machine) on a Linux/SPARC64 box with Mono (hello.exe simply printf >> "Hello World"): >> >> $ ls >> gcc4net.dll hello.exe libstd.dll MSCorelibWrapper.dll >> $ mono hello.exe >> >> Unhandled Exception: System.NullReferenceException: Object reference not set >> to an instance of an object >> at libstd.Obj?10?COBJ?init () [0x00000] in <filename unknown>:0 >> at libstd..init () [0x00000] in <filename unknown>:0 >> at hello..init () [0x00000] in <filename unknown>:0 >> at hello..start (System.String[] args) [0x00000] in <filename unknown>:0 >> >> All the DLLs come from gcc4cli compiled on the x86 box. I thought these DLLs >> would work fine but this is not the case. >> So I tried to compile gcc4cli on the SPARC64 box in order to get these DLLs >> fine. But the build failed: >> >> $ ../../gcc-src/gcc/configure --target=cil32 --enable-languages=c >> --disable-bootstrap --prefix=/local/lafage/gcc/image >> --with-local-prefix=/local/lafage/gcc/image/cil32 >> --with-mpfr=/local/lafage/misc --with-gmp=/local/lafage/misc >> [...] >> $ make >> [...] >> if /udd/lafage/local/gcc/gcc-build/gcc/./gcc/xgcc >> -B/udd/lafage/local/gcc/gcc-build/gcc/./gcc/ >> -B/local/lafage/gcc/image/cil32/bin/ -B/local/lafage/gcc/image/cil32/lib/ >> -isystem /local/lafage/gcc/image/cil32/include -isystem >> /local/lafage/gcc/image/cil32/sys-include -DHAVE_CONFIG_H -I. >> -I../../../../../gcc-src/gcc/libstd/src -I.. -nostdinc -iwithprefix >> include -I../../../../../gcc-src/gcc/libstd/include -g -O2 -MT >> libstd_dll-__io_fout.o -MD -MP -MF ".deps/libstd_dll-__io_fout.Tpo" -c -o >> libstd_dll-__io_fout.o `test -f '__io_fout.c' || echo >> '../../../../../gcc-src/gcc/libstd/src/'`__io_fout.c; \ >> then mv -f ".deps/libstd_dll-__io_fout.Tpo" >> ".deps/libstd_dll-__io_fout.Po"; else rm -f >> ".deps/libstd_dll-__io_fout.Tpo"; exit 1; fi >> /tmp/ccKF1tBh.s (2014, 36): >> Unhandled Exception: System.ArgumentException: Destination array is not long >> enough to copy all the items in the collection. Check array index and >> length. >> at System.BitConverter.PutBytes (System.Byte* dst, System.Byte[] src, >> Int32 start_index, Int32 count) [0x00000] in <filename unknown>:0 >> at System.BitConverter.ToDouble (System.Byte[] value, Int32 startIndex) >> [0x00000] in <filename unknown>:0 >> at Mono.ILASM.ILParser.yyparse (yyInput yyLex) [0x00000] in <filename >> unknown>:0 >> at Mono.ILASM.ILParser.yyparse (yyInput yyLex, System.Object yyd) >> [0x00000] in <filename unknown>:0 >> at Mono.ILASM.Driver+DriverMain.ProcessFile (System.String file_path) >> [0x00000] in <filename unknown>:0 >> make[4]: *** [libstd_dll-__io_fout.o] Error 1 >> >> Note that I recompiled mpfr and gmp in 32-bit mode. >> >> So I have 2 questions: >> >> Is it normal that gcc4li DLLs are not portable since they are .NET >> assemblies? >> Are there special configuration options to compile gcc4cli on SPARC64? >> >> Thanks for any help, >> >> Thierry Lafage. >> |
|
From: Thierry L. <thi...@in...> - 2010-03-08 16:39:47
|
Index: gcc/config/cil32/cil-lower.c
===================================================================
--- gcc/config/cil32/cil-lower.c (revision 156016)
+++ gcc/config/cil32/cil-lower.c (working copy)
@@ -1,6 +1,6 @@
/* CIL IR lowering.
- Copyright (C) 2009 Free Software Foundation, Inc.
+ Copyright (C) 2009-2010 Free Software Foundation, Inc.
This file is part of GCC.
@@ -23,11 +23,13 @@
Andrea C. Ornstein
Erven Rohou
Gabriele Svelto
+ Thierry Lafage
Contact information at STMicroelectronics:
Andrea C. Ornstein <and...@st...>
Contact information at INRIA:
Erven Rohou <erv...@in...>
+Thierry Lafage <thi...@in...>
*/
#include <stdio.h>
@@ -52,6 +54,8 @@
* Globals *
******************************************************************************/
+extern int flag_tree_vectorize; // TL // This avoids including options.h
+
enum simd_backend simd_type = UNDEF_SIMD;
/******************************************************************************
@@ -591,8 +595,7 @@
static bool
lower_cil_gate (void)
{
- /* FIXME: should lower only if vector types are handled in this funtion. */
- return true;
+ return flag_tree_vectorize != 0;
}
|
|
From: Thierry L. <thi...@in...> - 2010-03-04 14:27:34
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=UTF-8" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> Hi, <br> <br> In fact, for the second problem, I used -S to compare the assembly files and they are the same (SPARC one compared to x86 one). <br> Then, I successfully compiled and installed Mono (2.6.1+patch for Sparc from <a class="moz-txt-link-freetext" href="https://bugzilla.novell.com/show_bug.cgi?id=566298">https://bugzilla.novell.com/show_bug.cgi?id=566298</a>) on my SPARC box, but the ilasm problem is still the same :<br> <blockquote><font color="#993300"><tt>Unhandled Exception: System.ArgumentException: Destination array is not long enough to copy all the items in the collection. Check array index and length.<br> at System.BitConverter.PutBytes (System.Byte* dst, System.Byte[] src, Int32 start_index, Int32 count) [0x00000] in <filename unknown>:0<br> at System.BitConverter.ToDouble (System.Byte[] value, Int32 startIndex) [0x00000] in <filename unknown>:0<br> at Mono.ILASM.ILParser.yyparse (yyInput yyLex) [0x00000] in <filename unknown>:0<br> at Mono.ILASM.ILParser.yyparse (yyInput yyLex, System.Object yyd) [0x00000] in <filename unknown>:0<br> at Mono.ILASM.Driver+DriverMain.ProcessFile (System.String file_path) [0x00000] in <filename unknown>:0</tt></font><br> </blockquote> The problematic source asm is:<br> <blockquote><font color="#993300"><tt>ldc.r8 float64(0x41dfffffffc00000) /* 2.147483647e+9 */</tt></font><br> </blockquote> It seems that SystemToDouble() does not manage to convert the constant because its byte[] parameter is not long enough (should be 8, but ...?)<br> I suspect something's wrong in ilasm build (jay?), but I don't know what. If you have any clue, feel free to share <span class="moz-smiley-s3"><span> ;-) </span></span><br> <br> <pre class="moz-signature" cols="72">Thierry Lafage. </pre> <br> <br> Andrea Carlo Ornstein a écrit : <blockquote cite="mid:b1d...@ma..." type="cite"> <pre wrap="">Hi, the libraries are in pure CLI and are portable in compatible machine families (same pointer size, same endianness). by default we compile little endian, 32bit pointer size the 64bit pointer size was in the plans but we never got the time to actually do it. Now, looking at the errors you report. The first one, I guess was already reported from Erven and it's probably an error in Mono if I recall it correctly it mishandled a CLI copy object instruction when passed an unmanaged pointer (it happens in initialization of global variables) The second problem you have is in the assembler. you can compile with -S and see how the assembly file looks like, it should be the same on x86 and on sparc. If so the error is in the as tool you are using that is ilasm (from Mono again). Andrea On Wed, Mar 3, 2010 at 11:29 AM, Thierry Lafage <a class="moz-txt-link-rfc2396E" href="mailto:thi...@in..."><thi...@in...></a> wrote: </pre> <blockquote type="cite"> <pre wrap="">Hi all, I'm currently in trouble to run a gcc4cli compiled CLI code (compiled on Linux/x86 machine) on a Linux/SPARC64 box with Mono (hello.exe simply printf "Hello World"): $ ls gcc4net.dll hello.exe libstd.dll MSCorelibWrapper.dll $ mono hello.exe Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object at libstd.Obj?10?COBJ?init () [0x00000] in <filename unknown>:0 at libstd..init () [0x00000] in <filename unknown>:0 at hello..init () [0x00000] in <filename unknown>:0 at hello..start (System.String[] args) [0x00000] in <filename unknown>:0 All the DLLs come from gcc4cli compiled on the x86 box. I thought these DLLs would work fine but this is not the case. So I tried to compile gcc4cli on the SPARC64 box in order to get these DLLs fine. But the build failed: $ ../../gcc-src/gcc/configure --target=cil32 --enable-languages=c --disable-bootstrap --prefix=/local/lafage/gcc/image --with-local-prefix=/local/lafage/gcc/image/cil32 --with-mpfr=/local/lafage/misc --with-gmp=/local/lafage/misc [...] $ make [...] if /udd/lafage/local/gcc/gcc-build/gcc/./gcc/xgcc -B/udd/lafage/local/gcc/gcc-build/gcc/./gcc/ -B/local/lafage/gcc/image/cil32/bin/ -B/local/lafage/gcc/image/cil32/lib/ -isystem /local/lafage/gcc/image/cil32/include -isystem /local/lafage/gcc/image/cil32/sys-include -DHAVE_CONFIG_H -I. -I../../../../../gcc-src/gcc/libstd/src -I.. -nostdinc -iwithprefix include -I../../../../../gcc-src/gcc/libstd/include -g -O2 -MT libstd_dll-__io_fout.o -MD -MP -MF ".deps/libstd_dll-__io_fout.Tpo" -c -o libstd_dll-__io_fout.o `test -f '__io_fout.c' || echo '../../../../../gcc-src/gcc/libstd/src/'`__io_fout.c; \ then mv -f ".deps/libstd_dll-__io_fout.Tpo" ".deps/libstd_dll-__io_fout.Po"; else rm -f ".deps/libstd_dll-__io_fout.Tpo"; exit 1; fi /tmp/ccKF1tBh.s (2014, 36): Unhandled Exception: System.ArgumentException: Destination array is not long enough to copy all the items in the collection. Check array index and length. at System.BitConverter.PutBytes (System.Byte* dst, System.Byte[] src, Int32 start_index, Int32 count) [0x00000] in <filename unknown>:0 at System.BitConverter.ToDouble (System.Byte[] value, Int32 startIndex) [0x00000] in <filename unknown>:0 at Mono.ILASM.ILParser.yyparse (yyInput yyLex) [0x00000] in <filename unknown>:0 at Mono.ILASM.ILParser.yyparse (yyInput yyLex, System.Object yyd) [0x00000] in <filename unknown>:0 at Mono.ILASM.Driver+DriverMain.ProcessFile (System.String file_path) [0x00000] in <filename unknown>:0 make[4]: *** [libstd_dll-__io_fout.o] Error 1 Note that I recompiled mpfr and gmp in 32-bit mode. So I have 2 questions: Is it normal that gcc4li DLLs are not portable since they are .NET assemblies? Are there special configuration options to compile gcc4cli on SPARC64? Thanks for any help, Thierry Lafage. ------------------------------------------------------------------------------ Download Intel&#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. <a class="moz-txt-link-freetext" href="http://p.sf.net/sfu/intel-sw-dev">http://p.sf.net/sfu/intel-sw-dev</a> _______________________________________________ Gcc4cli-devel mailing list <a class="moz-txt-link-abbreviated" href="mailto:Gcc...@li...">Gcc...@li...</a> <a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/gcc4cli-devel">https://lists.sourceforge.net/lists/listinfo/gcc4cli-devel</a> </pre> </blockquote> </blockquote> </body> </html> |
|
From: Andrea C. O. <and...@gm...> - 2010-03-03 11:20:15
|
Hi, the libraries are in pure CLI and are portable in compatible machine families (same pointer size, same endianness). by default we compile little endian, 32bit pointer size the 64bit pointer size was in the plans but we never got the time to actually do it. Now, looking at the errors you report. The first one, I guess was already reported from Erven and it's probably an error in Mono if I recall it correctly it mishandled a CLI copy object instruction when passed an unmanaged pointer (it happens in initialization of global variables) The second problem you have is in the assembler. you can compile with -S and see how the assembly file looks like, it should be the same on x86 and on sparc. If so the error is in the as tool you are using that is ilasm (from Mono again). Andrea On Wed, Mar 3, 2010 at 11:29 AM, Thierry Lafage <thi...@in...> wrote: > Hi all, > > I'm currently in trouble to run a gcc4cli compiled CLI code (compiled on > Linux/x86 machine) on a Linux/SPARC64 box with Mono (hello.exe simply printf > "Hello World"): > > $ ls > gcc4net.dll hello.exe libstd.dll MSCorelibWrapper.dll > $ mono hello.exe > > Unhandled Exception: System.NullReferenceException: Object reference not set > to an instance of an object > at libstd.Obj?10?COBJ?init () [0x00000] in <filename unknown>:0 > at libstd..init () [0x00000] in <filename unknown>:0 > at hello..init () [0x00000] in <filename unknown>:0 > at hello..start (System.String[] args) [0x00000] in <filename unknown>:0 > > All the DLLs come from gcc4cli compiled on the x86 box. I thought these DLLs > would work fine but this is not the case. > So I tried to compile gcc4cli on the SPARC64 box in order to get these DLLs > fine. But the build failed: > > $ ../../gcc-src/gcc/configure --target=cil32 --enable-languages=c > --disable-bootstrap --prefix=/local/lafage/gcc/image > --with-local-prefix=/local/lafage/gcc/image/cil32 > --with-mpfr=/local/lafage/misc --with-gmp=/local/lafage/misc > [...] > $ make > [...] > if /udd/lafage/local/gcc/gcc-build/gcc/./gcc/xgcc > -B/udd/lafage/local/gcc/gcc-build/gcc/./gcc/ > -B/local/lafage/gcc/image/cil32/bin/ -B/local/lafage/gcc/image/cil32/lib/ > -isystem /local/lafage/gcc/image/cil32/include -isystem > /local/lafage/gcc/image/cil32/sys-include -DHAVE_CONFIG_H -I. > -I../../../../../gcc-src/gcc/libstd/src -I.. -nostdinc -iwithprefix > include -I../../../../../gcc-src/gcc/libstd/include -g -O2 -MT > libstd_dll-__io_fout.o -MD -MP -MF ".deps/libstd_dll-__io_fout.Tpo" -c -o > libstd_dll-__io_fout.o `test -f '__io_fout.c' || echo > '../../../../../gcc-src/gcc/libstd/src/'`__io_fout.c; \ > then mv -f ".deps/libstd_dll-__io_fout.Tpo" > ".deps/libstd_dll-__io_fout.Po"; else rm -f > ".deps/libstd_dll-__io_fout.Tpo"; exit 1; fi > /tmp/ccKF1tBh.s (2014, 36): > Unhandled Exception: System.ArgumentException: Destination array is not long > enough to copy all the items in the collection. Check array index and > length. > at System.BitConverter.PutBytes (System.Byte* dst, System.Byte[] src, > Int32 start_index, Int32 count) [0x00000] in <filename unknown>:0 > at System.BitConverter.ToDouble (System.Byte[] value, Int32 startIndex) > [0x00000] in <filename unknown>:0 > at Mono.ILASM.ILParser.yyparse (yyInput yyLex) [0x00000] in <filename > unknown>:0 > at Mono.ILASM.ILParser.yyparse (yyInput yyLex, System.Object yyd) > [0x00000] in <filename unknown>:0 > at Mono.ILASM.Driver+DriverMain.ProcessFile (System.String file_path) > [0x00000] in <filename unknown>:0 > make[4]: *** [libstd_dll-__io_fout.o] Error 1 > > Note that I recompiled mpfr and gmp in 32-bit mode. > > So I have 2 questions: > > Is it normal that gcc4li DLLs are not portable since they are .NET > assemblies? > Are there special configuration options to compile gcc4cli on SPARC64? > > Thanks for any help, > > Thierry Lafage. > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Gcc4cli-devel mailing list > Gcc...@li... > https://lists.sourceforge.net/lists/listinfo/gcc4cli-devel > > |
|
From: Thierry L. <thi...@in...> - 2010-03-03 11:19:55
|
Hi Gabriele, Thanks for your answer. For gcc4cli compilation, I've just realised that the build did not use the version of mono I wanted. It used an old 1.9.1 instead of the 2.6.1... Rebuild is on the way now... Thierry Lafage. Gabriele Svelto a écrit : > Hi Thierry, > > 2010/3/3 Thierry Lafage <thi...@in...>: > >> Hi all, >> >> [snip] >> >> So I have 2 questions: >> >> Is it normal that gcc4li DLLs are not portable since they are .NET >> assemblies? >> > > Yes, it is normal because the structures layout is tied to 32-bit > little-endian architectures (i.e. pointer are 32-bit large, bit-fields > are arranged in little-endian fashion, etc...). On top of that SPARC64 > requires 64-bit alignment for all 64-bit operands (including long > integers, and floating-point doubles, not only pointers) something > that the CLI-BE layout engine doesn't enforce. > > >> Are there special configuration options to compile gcc4cli on SPARC64? >> > > If I remember correctly we should have a big-endian switch somewhere > which might help but it won't fix the alignment/layout problems, aside > from that you must make sure that on the SPARC64 you are using the > 32-bit version of Mono and its libraries as we have no support for > 64-bit architectures. > > Gabriele Svelto > |
|
From: Gabriele S. <gab...@gm...> - 2010-03-03 11:13:44
|
Hi Thierry, 2010/3/3 Thierry Lafage <thi...@in...>: > Hi all, > > [snip] > > So I have 2 questions: > > Is it normal that gcc4li DLLs are not portable since they are .NET > assemblies? Yes, it is normal because the structures layout is tied to 32-bit little-endian architectures (i.e. pointer are 32-bit large, bit-fields are arranged in little-endian fashion, etc...). On top of that SPARC64 requires 64-bit alignment for all 64-bit operands (including long integers, and floating-point doubles, not only pointers) something that the CLI-BE layout engine doesn't enforce. > Are there special configuration options to compile gcc4cli on SPARC64? If I remember correctly we should have a big-endian switch somewhere which might help but it won't fix the alignment/layout problems, aside from that you must make sure that on the SPARC64 you are using the 32-bit version of Mono and its libraries as we have no support for 64-bit architectures. Gabriele Svelto |
|
From: Thierry L. <thi...@in...> - 2010-03-03 11:04:50
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> </head> <body bgcolor="#ffffff" text="#000000"> Hi all,<br> <br> I'm currently in trouble to run a gcc4cli compiled CLI code (compiled on Linux/x86 machine) on a Linux/SPARC64 box with Mono (hello.exe simply printf "Hello World"):<br> <blockquote><font color="#993300"><tt>$ ls<br> gcc4net.dll hello.exe libstd.dll MSCorelibWrapper.dll<br> $ mono hello.exe<br> <br> Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object<br> at libstd.Obj?10?COBJ?init () [0x00000] in <filename unknown>:0<br> at libstd..init () [0x00000] in <filename unknown>:0<br> at hello..init () [0x00000] in <filename unknown>:0<br> at hello..start (System.String[] args) [0x00000] in <filename unknown>:0</tt></font><br> </blockquote> All the DLLs come from gcc4cli compiled on the x86 box. I thought these DLLs would work fine but this is not the case.<br> So I tried to compile gcc4cli on the SPARC64 box in order to get these DLLs fine. But the build failed:<br> <blockquote><font color="#993300"><tt>$ ../../gcc-src/gcc/configure --target=cil32 --enable-languages=c --disable-bootstrap --prefix=/local/lafage/gcc/image --with-local-prefix=/local/lafage/gcc/image/cil32 --with-mpfr=/local/lafage/misc --with-gmp=/local/lafage/misc<br> [...]<br> $ make<br> [...]<br> if /udd/lafage/local/gcc/gcc-build/gcc/./gcc/xgcc -B/udd/lafage/local/gcc/gcc-build/gcc/./gcc/ -B/local/lafage/gcc/image/cil32/bin/ -B/local/lafage/gcc/image/cil32/lib/ -isystem /local/lafage/gcc/image/cil32/include -isystem /local/lafage/gcc/image/cil32/sys-include -DHAVE_CONFIG_H -I. -I../../../../../gcc-src/gcc/libstd/src -I.. -nostdinc -iwithprefix include -I../../../../../gcc-src/gcc/libstd/include -g -O2 -MT libstd_dll-__io_fout.o -MD -MP -MF ".deps/libstd_dll-__io_fout.Tpo" -c -o libstd_dll-__io_fout.o `test -f '__io_fout.c' || echo '../../../../../gcc-src/gcc/libstd/src/'`__io_fout.c; \</tt><br> <tt> then mv -f ".deps/libstd_dll-__io_fout.Tpo" ".deps/libstd_dll-__io_fout.Po"; else rm -f ".deps/libstd_dll-__io_fout.Tpo"; exit 1; fi</tt><br> <tt>/tmp/ccKF1tBh.s (2014, 36):</tt><br> <tt>Unhandled Exception: System.ArgumentException: Destination array is not long enough to copy all the items in the collection. Check array index and length.</tt><br> <tt> at System.BitConverter.PutBytes (System.Byte* dst, System.Byte[] src, Int32 start_index, Int32 count) [0x00000] in <filename unknown>:0</tt><br> <tt> at System.BitConverter.ToDouble (System.Byte[] value, Int32 startIndex) [0x00000] in <filename unknown>:0</tt><br> <tt> at Mono.ILASM.ILParser.yyparse (yyInput yyLex) [0x00000] in <filename unknown>:0</tt><br> <tt> at Mono.ILASM.ILParser.yyparse (yyInput yyLex, System.Object yyd) [0x00000] in <filename unknown>:0</tt><br> <tt> at Mono.ILASM.Driver+DriverMain.ProcessFile (System.String file_path) [0x00000] in <filename unknown>:0</tt><br> <tt>make[4]: *** [libstd_dll-__io_fout.o] Error 1</tt></font><br> </blockquote> Note that I recompiled mpfr and gmp in 32-bit mode.<br> <br> So I have 2 questions:<br> <ol> <li>Is it normal that gcc4li DLLs are not portable since they are .NET assemblies?</li> <li>Are there special configuration options to compile gcc4cli on SPARC64?</li> </ol> Thanks for any help,<br> <pre class="moz-signature" cols="72">Thierry Lafage. </pre> </body> </html> |
|
From: Erven R. <erv...@in...> - 2010-02-19 15:11:31
|
Hello, We used to have a flag -mexpand-minmax. Actually, the flag is still here, but it does nothing. I checked 'svn log', but I could not find much. Does anybody remember what happened? We always emit a call to min or max? -- Erven. |
|
From: Erven R. <erv...@in...> - 2010-02-19 10:38:56
|
Gabriele Svelto a écrit : > 2010/2/19 Erven Rohou <erv...@in...>: >> Ciao, >> >> Many benchmarks (unfortunately) use setjmp and longjmp, which we do not support. >> However, longjmp is often used to handle exceptional situations, mostly errors. >> Here is a proposal: we could define setjmp to return 0, and longjmp to abort (or >> print a message and abort,...) We could compile and run benchmarks that do not >> have errors. Probably we keep a warning in the header file. >> What do you think? > > Sounds like a good idea, I believe most of the stuff will work well > under normal conditions. > > Gabriele > Here is a patch for libstd. Please let me know if you have any comment. As usual I am having problems with automake/autoconf/etc. I modified Makefile.am to add the file setjmp.c. autoreconf generated lots of stuff that breaks my build. So I patched Makefile.in by hand. It seems that some tool also modified config.h.in and configure. Anyway, if somebody has an idea, I am willing do it properly. :-) -- Erven. |
