Re: gcc wiki project

2015-04-06 Thread Gerald Pfeifer 
On Mon, 23 Mar 2015, David Kunsman wrote:
> Hello, I was just reading through the current projects wiki page and I
> noticed how out of date pretty much all of them are.  So I was
> planning on doing "spring cleaning" by going down the list tracking
> down what has been and what needs to be down and updating all the
> wikis.  Do you think this is something that is worthwhile to work on?

This is an awesome idea.

Note there also is https://gcc.gnu.org/projects/ which is even older,
and for any changes you want to make there I'd be happy to help you
(and apply a patch, cf. https://gcc.gnu.org/about.html , or follow 
verbal descriptions).

Gerald

Re: Question about Gimple FE

2015-04-06 Thread Segher Boessenkool 
On Fri, Apr 03, 2015 at 09:25:57AM -0600, Jeff Law wrote:
> On 04/03/2015 07:45 AM, Diego Novillo wrote:
> >Not quite. The output of the debug dumpers is not really meant to be fed
> >back to the compiler. They are debug dumps only. They do not contain
> >enough information for code generation or analysis.

> But that's something that could be fixed.

Please please please no.  It already is annoying enough that many
times when you add something to a debug dump, testsuite tests all
over start failing.  Let's keep the dump files to be just for
textual debug.


Segher

Generating gimple code with gimple_build_assign

2015-04-06 Thread Steve Ellcey 
I have a simple gimple question.  I am trying to introduce an array
into a gimple stream and create a pointer to that array.

I can create the array with:

array_type = build_array_type_nelts (char_type_node, 256);
array_var = create_tmp_var (array_type, "spill");

I can create a pointer to an array with:

ptr_type = build_pointer_type (array_type);
ptr_var = create_tmp_var (ptr_type, "spill");

But if I try to create an assignment to get the pointer to point to
the array I get a verify_gimple error.

I have tried:

stmt = gimple_build_assign (ptr_var, array_var);
and
stmt = gimple_build_assign (ptr_var, ADDR_EXPR, array_var);

but neither of those work.  I also tried making the pointer be a
pointer to char instead of a pointer to array of char but that didn't
seem to work either.  Can someone help me with the magic formula to
generate gimple code that causes ptr_var to point to array_var?
Is ADDR_EXPR the right way to get the address of the array instead of
the value in a gimple_build_assign call?

Steve Ellcey
sell...@imgtec.com

Re: FW: Question about Gimple FE

2015-04-06 Thread Sebastian Pop 
On Fri, Apr 3, 2015 at 1:10 PM, Jeff Law  wrote:
> On 04/03/2015 09:41 AM, Diego Novillo wrote:
>>
>> On Fri, Apr 3, 2015 at 11:35 AM, Jeff Law  wrote:
>> I was hesitant to offer this option, but it's certainly a good
>> starting point.  The representation encodes CFG, SSA, attributes,
>> declarations and annotations.  It has a relatively fixed syntax, which
>> makes it easy to parse.
>
>
> Certainly using LLVM's textual format opens up a significant cans of worms,
> but there's some obvious (and some less than obvious) benefits.

I also want to mention that LLVM's IR is not an equivalent of GCC's IR:
for instance, in GCC we have multi dimensional array types that are
missing in LLVM.

Having an IR that is more readable than LLVM's would be nice.

Thanks,
Sebastian

Partial inline on recursive functions?

2015-04-06 Thread Tim Shen 
Hi there,

I found the C++11 code below:
  int Fib(int n) {
  if (n <= 1) return n;
  return [&] { return Fib(n-2) + Fib(n-1); }();
  }

is ~2x faster than normal one:
  int Fib(int n) {
  if (n <= 1) return n;
  return Fib(n-2) + Fib(n-1);
  }

I tested them with "-std=c++11 -O3/-O2" using trunk and the first
version is ~2x (1.618x in theory?) faster. However, the first version
has larger binary size (101k compared to 3k, which is for the second
version). Clang produces 4k for the first version (with similar speed
improvement) though.

My guess is that the first `if (n <= 1) return n;` is easier to inline
into the caller side, since the returned expression is a call to a
separated function. It's translated to something like (ignoring
linkage difference):
  int foo(int n);
  int Fib(int n) {
  if (n <= 1) {
  return n;
  }
  return foo(n);
  }
  int foo(int n) {
  return Fib(n-2) + Fib(n-1);
  };

After inline optimizations, it's translated to:
  int foo(int n);
  int Fib(int n) {
  if (n <= 1) {
  return n;
  }
  return foo(n);
  }
  int foo(int n) {
  return (n-2<=1) ? n-2 : foo(n-2) + (n-1<=1) ? n-1 : foo(n-1);
  };

As a result, the maximum depth of the stack reduces by 1, since all
boundary checkings (if (n <= 1) return n;) are done by the caller
side, which may eliminate unnecessary function call overhead.

To me the optimization should be: For a given recursive function A,
split it into function B and C, so that A is equivalent to { B();
return C(); }, where B should be easy to inline (e.g. no recursive
calls) and C may not.

Is it possible/reasonable to do such an optimization? I hope it can help. :)

Thanks!


-- 
Regards,
Tim Shen