Re: GCC 4.3.0 Status Report (2008-01-02)
On Wed, Jan 02, 2008 at 04:13:51PM -0800, Mark Mitchell wrote: > In the latest batch, I did notice several bugs with relatively exotic > options (e.g., "-fopenmp", "-ftest-coverage", and "-fmudflap".) I don't think that the first two are exotic at all. Many developers use coverage testing extensively, so -ftest-coverage gets lots of use. OpenMP is also getting increasing levels of attention as the world realizes it's going to have to learn to program in parallel. Of course, those options in combination with other options might be exotic. I don't get the impression that mudflap gets much use, though.
Re: __builtin_expect for indirect function calls
If possible, I agree it seems natural to extend __builtin_expect. My concern would be backwards compatibility. Currently, the prototype for __builtin_expect is long __builtin_expect (long expression, long constant); Extending it to functions would change it to T __builtin_expect (T expression, T expected); With these additional semantics and restrictions: - when the return value is being used as a call expression: * T is the type of 'expression' * 'expected' is allowed to be a non-constant - when the return value is not being used as a call expression: * T is type 'long; * 'expected' must be a compile-time constant Given the above definition, I don't think there is any backwards compatibility issues because we are inspecting the context of the use of __builtin_expect. Rather than the above definition, we could choose not to inspect the context and just say: * T is the type of 'expression' * 'expected' is allowed to be a non-constant In this case I think there would only be compatibility issues with unusual uses of __builtin_expect, for example, if it was being used in a function argument and its type effected overload resolution. Or if the argument was a float and was being implicitly converted to a long (with a warning). There would also be code which previously gave warnings but does not with the extended __builtin_expect. I'm ok with either of these definitions, if extending __builtin_expect is the preferred way to go. Are either of these definitions ok? Or are there other ideas how to define it? Trevor * Mark Mitchell <[EMAIL PROTECTED]> [2008-01-03 12:12]: > Hans-Peter Nilsson wrote: > > On Mon, 17 Dec 2007, [EMAIL PROTECTED] wrote: > >> When we can't hint the real target, we want to hint the most common > >> target. There are potentially clever ways for the compiler to do this > >> automatically, but I'm most interested in giving the user some way to do > >> it explicitly. One possiblity is to have something similar to > >> __builtin_expect, but for functions. For example, I propose: > >> > >> __builtin_expect_call (FP, PFP) > > > > Is there a hidden benefit? I mean, isn't this really > > expressable using builtin_expect as-is, at least when it comes > > to the syntax? > > That was my first thought as well. Before we add __builtin_expect_call, > I think there needs to be a justification of why this can't be done with > __builtin_expect as-is. > > -- > Mark Mitchell > CodeSourcery > [EMAIL PROTECTED] > (650) 331-3385 x713
Re: __builtin_expect for indirect function calls
> >
> > which returns the value of FP with the same type as FP, and tells the
> > compiler that PFP is the expected target of FP. Trival examples:
> >
> > typedef void (*fptr_t)(void);
> >
> > extern void foo(void);
> >
> > void
> > call_fp (fptr_t fp)
> > {
> > /* Call the function pointed to by fp, but predict it as if it is
> >calling foo() */
> > __builtin_expect_call (fp, foo)();
>
> __builtin_expect (fp, foo); /* alt __builtin_expect (fp == foo, 1); */
> fp ();
> > }
> >
> > void
> > call_fp_predicted (fptr_t fp, fptr_t predicted)
> > {
> > /* same as above but the function we are calling doesn't have to be
> >known at compile time */
> > __builtin_expect_call (fp, predicted)();
>
> __builtin_expect (fp, predicted);
> fp();
>
> I guess the information just isn't readily available in the
> preferred form when needed and *that* part could more or less
> simply be fixed?
The main reason I didn't like this is that in some other context 'fp'
could be any expression, potentially with side effects. This would
require either special handling by the compiler, or the user would have
to be sure to write it such that the side effects only happen once.
Trevor
Re: MPFR 2.3.1 Release Candidate
On Wed, 2 Jan 2008, Vincent Lefevre wrote: > See the new bug fixed in r5162 (for the 2.3 branch). mpfr_gamma on > -11.5 will give you -0 instead of +0. So I tried that, but mpfr_gamma on that value sets the global underflow flag. If overflow/underflow are set by mpfr, GCC will intentionally bypass folding. So this particular case is not something I can use. I don't know if this mpfr case should be setting the underflow flag or if it's a bug. Calling the glibc tgamma doesn't seem to think it underflowed when looking at fetestexcept(). --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
Re: plugin help: Inserting a function call in gimple code?
Hi,
On Wed, Jan 02, 2008 at 06:13:37PM -0500, Rob Johnson wrote:
> I'm experimenting with the gimple plugin infrastructure and I'm having
> trouble instrumenting code in a way that is compatible with the optimizer.
> Here's a simple example that is intended to insert the function call
> "__memcheck_register_argv(argc, argv)" at the beginning of main. The code
> runs during pass_plugin_gimple (which comes right after pass_apply_inline
> in passes.c) and works great with -O0, but causes the compiler to crash
> with -O1 or higher.
>
> -
> tree argv_registrar_type;
> tree argv_registrar;
> tree argv_registrar_call;
>
> argv_registrar_type = build_function_type_list (void_type_node,
> integer_type_node,
> build_pointer_type
> (build_pointer_type
> (char_type_node)),
> NULL_TREE);
> argv_registrar = build_fn_decl ("__memcheck_register_argv",
> argv_registrar_type);
> argv_registrar_call = build_call_expr (argv_registrar, 2,
>DECL_ARGUMENTS (cfun->decl),
>TREE_CHAIN (DECL_ARGUMENTS
>(cfun->decl)));
DECL_ARGUMENTS is a tree chain of PARM_DECLs and in SSA GIMPLE, scalar
operands (integers and pointer are both scalar, is_gimple_reg()
predicate is there to identify variables that need to be converted to
SSA) need to be SSA_NAMEs of declarations (PARM_DECLs and VAR_DECLs in
particular).
Therefore I suspect you need to create a different chain of respective
SSA_NAMES and pass that to build_call_expr(). You can get the default
SSA_NAME by calling gimple_default_def().
> bsi_insert_before (&iter, argv_registrar_call, BSI_SAME_STMT);
> ---
>
> With -O1, I get the compiler failure
>
> ---
> test.c: In function 'main':
> test.c:2: error: expected an SSA_NAME object
> test.c:2: error: in statement
> __memcheck_register_argv (argc, argv);
> test.c:2: internal compiler error: verify_ssa failed
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See http://gcc.gnu.org/bugs.html> for instructions.
>
>
> when attempting to compile the code
>
> -
> int main(int argc, char **argv)
> {
> return 0;
> }
> -
>
>
HTH
Martin
Re: Optimizations documentation
> Ira Rosen wrote: > > Here is the link to the vectorizer's documentation: > > http://gcc.gnu.org/projects/tree-ssa/vectorization.html > > > > > > > Thanks, but I take what it says there with some grains of salt. ?? please report any inaccuracies/outdated information you find, I'd like to fix any such issues. > Yes, > -O3 implies -ftree-vectorize on x86_64, but I seem to have to specify > the option on other targets. tree-vectorize is enabled under -O3, for all targets. I don't know of any target that disabled it. There may be however targets that require additional flags to enable vectorization (like -maltivec for powerpc). Specifically, on which targets does "-O3" behaves differently than "-O3 -ftree-vectorize"? > Also, I have not understood the > limitations of -freassociative-math. I think this is a typo - should be "-fassociative-math" (I'll fix that; here's the related thread: http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00183.html). > Several gcc vectorization test cases currently throw FAIL on certain > targets, but not on others. I don't know if that is a significant issue. please report specific testcases+targets... (there are already at least a couple open PRs for failing testcases - 34168 and 34437 are the most recent ones I think. there may be more). > g++-4.3 seems well ahead of other compilers in ability to vectorize STL > iterators: > http://softwarecommunity.intel.com/Wiki/HighPerformanceComputing/688.htm > good to know. I browsed over the posting above; do you have a summary table where one could easily see which loops get vectorized by other compilers and not by gcc (and vice versa)? thanks, dorit
Re: [PATCH] Disallow inlining if static vars in that function contain addresses of that function's labels (PR tree-optimization/29484)
Jakub Jelinek <[EMAIL PROTECTED]> writes: > Smalltalk example Paolo mentioned will work just fine, GCC won't > try to inline that function, and I think we should keep it that way. FWIW Older versions of the Linux kernel used &&label in an inline to get the current text address for debugging output purposes. Of course no requirement that it is unique. While that has changed it would be good if that still worked. In particular not inlining that function would probably cause significant code growth. -Andi
Re: plugin help: Inserting a function call in gimple code?
Martin Jambor wrote:
Hi,
On Wed, Jan 02, 2008 at 06:13:37PM -0500, Rob Johnson wrote:
I'm experimenting with the gimple plugin infrastructure and I'm having
trouble instrumenting code in a way that is compatible with the optimizer.
Here's a simple example that is intended to insert the function call
"__memcheck_register_argv(argc, argv)" at the beginning of main. The code
runs during pass_plugin_gimple (which comes right after pass_apply_inline
in passes.c) and works great with -O0, but causes the compiler to crash
with -O1 or higher.
-
tree argv_registrar_type;
tree argv_registrar;
tree argv_registrar_call;
argv_registrar_type = build_function_type_list (void_type_node,
integer_type_node,
build_pointer_type
(build_pointer_type
(char_type_node)),
NULL_TREE);
argv_registrar = build_fn_decl ("__memcheck_register_argv",
argv_registrar_type);
argv_registrar_call = build_call_expr (argv_registrar, 2,
DECL_ARGUMENTS (cfun->decl),
TREE_CHAIN (DECL_ARGUMENTS
(cfun->decl)));
DECL_ARGUMENTS is a tree chain of PARM_DECLs and in SSA GIMPLE, scalar
operands (integers and pointer are both scalar, is_gimple_reg()
predicate is there to identify variables that need to be converted to
SSA) need to be SSA_NAMEs of declarations (PARM_DECLs and VAR_DECLs in
particular).
Therefore I suspect you need to create a different chain of respective
SSA_NAMES and pass that to build_call_expr(). You can get the default
SSA_NAME by calling gimple_default_def().
Yes! It seems it's slightly more complicated given that, with some
optimization levels the code is sometimes turned into SSA and sometimes
not, and that, depending on how the original program uses argv and argc,
they may or may not already have default definitions. If the original
program doesn't touch argv/argc, then we also have to update the set of
referenced vars. Here's the code I wrote to construct the argc argument
to the above call expression:
tree argc;
/* If we're doing SSA... */
if (cfun->gimple_df && cfun->gimple_df->default_defs)
{
argc = gimple_default_def (cfun, DECL_ARGUMENTS (cfun->decl));
if (!argc)
{
argc = DECL_ARGUMENTS (cfun->decl);
mark_sym_for_renaming (argc);
}
add_referenced_var (DECL_ARGUMENTS (cfun->decl));
}
else
argc = DECL_ARGUMENTS (cfun->decl);
The code for argv is similar. Does that look right?
Once I get this plugin working, I will try to extract some useful
building blocks for other plugin writers. Thanks for your help!
Best,
Rob
