Re: GCC internal re-architecture proposal

[Richard Biener]

On Tue, Mar 18, 2014 at 5:34 PM, Diego Novillo  wrote:
> On Tue, Mar 18, 2014 at 10:19 AM, Richard Biener
>  wrote:
>> On Fri, Jun 21, 2013 at 5:27 PM, Andrew MacLeod  wrote:
>>> [ I foolishly sent this with the document as an attachment... hopefully it
>>> gets rejected and anyone interested can simply download the document from
>>> the wiki..]
>>>
>>> Over the past couple of months, I've slowly been putting together an action
>>> plan to help modernize GCC's source base.  We've had various ideas put forth
>>> over the years, and a few of the more meritorious ones have been
>>> incorporated.  My primary goal is to disentangle the front end from the
>>> middle/back ends, giving us better control over their data structures.
>>>
>>> The biggest challenge is having an executable plan which allows the source
>>> to be updated incrementally.   Ie, we need a way to get from 'Here' to
>>> 'There' that does not impact ongoing normal activities, nor noticeably
>>> affect the performance of the compiler.  This is a huge effort and it will
>>> require a large time commitment on my part to see it through.
>>
>> Sorry for following up on this old e-mail but it just occured to me that
>> the (unfinished) GIMPLE frontend would be a great place to bootstrap
>> the new and shiny GIMPLE data structures.
>>
>> Of course for it to work you need to translate that back to fat-and-old 
>> GIMPLE
>> and eventually finish the textual format dumping as well - not sure what
>> the state of the gimple frontend branch is.
>
> Work on it stalled sometime last year.
>
> I'm not sure if I would mix the re-arch work with the GIMPLE FE work.
> The parser will take the most benefit out of the new structure, but I
> think it may be better to make the front end be a sub-branch of the
> re-architect work so we don't conflate the two.
>
> Some work will be independent, but it will be easier to maintain both
> branches if they are separate.
>
> I do like the idea of tying the GIMPLE front end to the re-arch
> branch, however. So, making it a sub-branch of re-arch is definitely a
> good idea.

Well, I thought that the GIMPLE FE itself is the easiest place where
you can try out things given that it has to represent all features
of GIMPLE but doesn't (necessarily) use the GIMPLE IL as its AST.
Especially the no-trees part should be easy there.  And we can be
convinced of the beauty of the new AST before munging all these
wrappers into trunk with the fear that only the wrappers will stay
and the project itself will never finish ... thus we get the ugliness
while with the GIMPLE FE we'd at least get the GIMPLE FE ...

Richard.

>
> Diego.

Re: [gsoc 2014] moving fold-const patterns to gimple

[Richard Biener]

On Tue, Mar 18, 2014 at 9:04 AM, Prathamesh Kulkarni
 wrote:
> On Mon, Mar 17, 2014 at 2:22 PM, Richard Biener
>  wrote:
>> On Sun, Mar 16, 2014 at 1:21 PM, Prathamesh Kulkarni
>>  wrote:
>>> In c_expr::c_expr, shouldn't OP_C_EXPR be passed to operand
>>> constructor instead of OP_EXPR ?
>>
>> Indeed - I have committed the fix.
>>
> Hi, I have attached an initial draft of my proposal.
> I would be grateful to receive your feedback.

Ok, I had a look at the proposal and it is mostly fine.  I'd be more specific
on the deliverables, specifically

1) genmatch - program to read meta description and generate code to
simplify GENERIC and GIMPLE according to the pattern descriptions
using an algorithm not linear in the number of patterns

2) add patterns matched by tree-ssa-forwprop.c (and thus patterns
in fold-const.c it depends on) to the meta-description and perform
the simplifications of tree-ssa-forwprop.c in terms of the simplification API

You will figure out that there are possibly a lot of patterns in fold-const.c
that forwprop depends on (I know mainly of all the comparison simplifications).

For the Timeline I'd move e) as a sub-task of f) to June 28 - July 16,
eventually just dividing the weeks of July 17 - August 11 to that and
the following task.

That is, the overall deliverable should be a tree-ssa-forwprop.c that is
(mostly) implemented in terms of patterns, ready for commit to trunk
during stage1.

As for targeting GENERIC, useful testing coverage of that path will
come from for example re-writing fold-const.c:fold_comparison using
the GENERIC API of the pattern simplifier.

The devil will be in the details (as always) ;)

As Maxim said - make sure to register your proposal in-time, you
can always improve on it later.

Thanks,
Richard.

> Thanks and Regards,
> Prathamesh
>> Thanks,
>> Richard.
>>
>>> This caused segfault for patterns when "simplification" operand was
>>> only c_expr (patch attached).
>>>
>>> * genmatch.c (c_expr::c_expr): use OP_C_EXPR instead of OP_EXPR in
>>> call to operand constructor.

Re: GCC internal re-architecture proposal

[Andrew MacLeod]

On 03/19/2014 05:08 AM, Richard Biener wrote:

On Tue, Mar 18, 2014 at 5:34 PM, Diego Novillo  wrote:

On Tue, Mar 18, 2014 at 10:19 AM, Richard Biener
 wrote:

On Fri, Jun 21, 2013 at 5:27 PM, Andrew MacLeod  wrote:

[ I foolishly sent this with the document as an attachment... hopefully it
gets rejected and anyone interested can simply download the document from
the wiki..]

Over the past couple of months, I've slowly been putting together an action
plan to help modernize GCC's source base.  We've had various ideas put forth
over the years, and a few of the more meritorious ones have been
incorporated.  My primary goal is to disentangle the front end from the
middle/back ends, giving us better control over their data structures.

The biggest challenge is having an executable plan which allows the source
to be updated incrementally.   Ie, we need a way to get from 'Here' to
'There' that does not impact ongoing normal activities, nor noticeably
affect the performance of the compiler.  This is a huge effort and it will
require a large time commitment on my part to see it through.

Sorry for following up on this old e-mail but it just occured to me that
the (unfinished) GIMPLE frontend would be a great place to bootstrap
the new and shiny GIMPLE data structures.

Of course for it to work you need to translate that back to fat-and-old GIMPLE
and eventually finish the textual format dumping as well - not sure what
the state of the gimple frontend branch is.

Work on it stalled sometime last year.

I'm not sure if I would mix the re-arch work with the GIMPLE FE work.
The parser will take the most benefit out of the new structure, but I
think it may be better to make the front end be a sub-branch of the
re-architect work so we don't conflate the two.

Some work will be independent, but it will be easier to maintain both
branches if they are separate.

I do like the idea of tying the GIMPLE front end to the re-arch
branch, however. So, making it a sub-branch of re-arch is definitely a
good idea.

Well, I thought that the GIMPLE FE itself is the easiest place where
you can try out things given that it has to represent all features
of GIMPLE but doesn't (necessarily) use the GIMPLE IL as its AST.
Especially the no-trees part should be easy there.  And we can be
convinced of the beauty of the new AST before munging all these
wrappers into trunk with the fear that only the wrappers will stay
and the project itself will never finish ... thus we get the ugliness
while with the GIMPLE FE we'd at least get the GIMPLE FE ...




Well, there are no new ASTs...The gimple IL is still the same, except 
we'll have an opportunity to better formalize it, and it will be 
statically type-safe rather than dynamic like today.  Its not really 
practical to maintain it on a branch all the way until a completely 
non-tree front end can be produced. There are too many "unrelated" 
issues to progress from where we are today to a separate front end.


That said, It has become necessary to start separating out the front end 
interface components shortly as part of the work.  This can use the 
gimple FE  as a litmus test.  Maybe we can drum up some interest and 
finish development of it.


In any case, no decisions have to be made yet, and I'm not planning to 
rush it.  I'm still refining things and it'll be a couple of months 
before its worth discussing any sort of integration plan or options.  I 
plan to put together some documentation during that time and we can 
discuss its merits and fate when that is ready.


I figure we can hash things out during the month leading up to Cauldron.

Andrew

returning short-enum and truncate doesn't trigger conversion warning

[Paulo Matos]

Hi all,

This is either a C standard subtlety or a bug in GCC.
For example:
unsigned short foo (unsigned int a)
{
  return a;
}

enum xpto
{
  A = 0,
  B = 1,
  X = 512
};

extern void print (unsigned int);

unsigned char bar (enum xpto a)
{
  print (sizeof (unsigned char));
  print (sizeof (enum xpto));
  return a;
}

$ ~/work/tmp/GCC/builds/gcc-trunk/gcc/cc1 -O2 test.c -Wall -Wconversion 
--short-enums -quiet
test.c: In function 'foo':
test.c:3:3: warning: conversion to 'short unsigned int' from 'unsigned int' may 
alter its value [-Wconversion]
   return a;
   ^

I was expecting a warning for bar as well since sizeof unsigned char is 1 and 
sizeof enum xpto is 2, therefore the value is truncated but no warning is 
issued.

Shall I open a PR?

Paulo Matos

Re: returning short-enum and truncate doesn't trigger conversion warning

[David Brown]

On 19/03/14 15:33, Paulo Matos wrote:
> Hi all,
> 
> This is either a C standard subtlety or a bug in GCC.

This is perfectly normal behaviour for C, and not a bug.  It is also a
topic for the gcc help list, rather than the development list.

> For example:
> unsigned short foo (unsigned int a)
> {
>   return a;
> }

This gives a conversion warning because a short unsigned int (16-bit on
x86) is smaller than an unsigned int (32-bit on x86).  So calling
foo(0x12345678) will cause truncation.

> 
> enum xpto
> {
>   A = 0,
>   B = 1,
>   X = 512
> };
> 
> extern void print (unsigned int);
> 
> unsigned char bar (enum xpto a)
> {
>   print (sizeof (unsigned char));
>   print (sizeof (enum xpto));
>   return a;
> }

The sizeof operator returns an integer of type size_t (typically the
same as unsigned int or unsigned long, depending on the platform
details).  But the compiler can see that the particular values in
question - 1 and 2 - can be converted to unsigned int without loss of
precision of changing the value.  Therefore no warning is giving.

> 
> $ ~/work/tmp/GCC/builds/gcc-trunk/gcc/cc1 -O2 test.c -Wall -Wconversion 
> --short-enums -quiet
> test.c: In function 'foo':
> test.c:3:3: warning: conversion to 'short unsigned int' from 'unsigned int' 
> may alter its value [-Wconversion]
>return a;
>^
> 
> I was expecting a warning for bar as well since sizeof unsigned char is 1 and 
> sizeof enum xpto is 2, therefore the value is truncated but no warning is 
> issued.
> 
> Shall I open a PR?
> 
> Paulo Matos
> 

RE: returning short-enum and truncate doesn't trigger conversion warning

[Paulo Matos]

> -Original Message-
> From: David Brown [mailto:da...@westcontrol.com]
> Sent: 19 March 2014 14:44
> To: Paulo Matos; gcc@gcc.gnu.org
> Subject: Re: returning short-enum and truncate doesn't trigger
> conversion warning
> 
> On 19/03/14 15:33, Paulo Matos wrote:
> > Hi all,
> >
> > This is either a C standard subtlety or a bug in GCC.
> 
> This is perfectly normal behaviour for C, and not a bug.  It is also a
> topic for the gcc help list, rather than the development list.
> 

Apologies, but I submitted this to gcc devel because I do think it is a bug.

> >
> > enum xpto
> > {
> >   A = 0,
> >   B = 1,
> >   X = 512
> > };
> >
> > extern void print (unsigned int);
> >
> > unsigned char bar (enum xpto a)
> > {
> >   print (sizeof (unsigned char));
> >   print (sizeof (enum xpto));
> >   return a;
> > }
> 
> The sizeof operator returns an integer of type size_t (typically the
> same as unsigned int or unsigned long, depending on the platform
> details).  But the compiler can see that the particular values in
> question - 1 and 2 - can be converted to unsigned int without loss of
> precision of changing the value.  Therefore no warning is giving.
>

512 cannot be converted to an unsigned char without loss of precision. 
The prints are actually not relevant for the question. They were just used for 
me to confirm the sizes of the types. 
enum xpto
{
  A = 0,
  B = 1,
  X = 512
};
extern void print (unsigned int);

unsigned char bar (enum xpto a)
{
   return a;
}

Variable a could be 0, 1 or 512. In case of the latter there is loss of 
precision but still no warning.
 
> >
> > $ ~/work/tmp/GCC/builds/gcc-trunk/gcc/cc1 -O2 test.c -Wall
> > -Wconversion --short-enums -quiet
> > test.c: In function 'foo':
> > test.c:3:3: warning: conversion to 'short unsigned int' from
> 'unsigned int' may alter its value [-Wconversion]
> >return a;
> >^
> >
> > I was expecting a warning for bar as well since sizeof unsigned char
> is 1 and sizeof enum xpto is 2, therefore the value is truncated but
> no warning is issued.
> >
> > Shall I open a PR?
> >
> > Paulo Matos
> >
> 
> 

[GSoC 2014] Proposal: OpenCL Code Generator

[Ilmir Usmanov]

Hi all!

My name is Ilmir Usmanov and I'm a student of Moscow Institute of Physics and 
Technology.
Also I'm implementing OpenACC 1.0 in gomp4 branch as an employee of Samsung R&D 
Institute Russia (SRR). My research interests are connected with creating 
OpenCL Code Generator. So I'd like to participate GSoC 2014 with project called 
"OpenCL Code Generator" as an independent student. I will do the project during 
my free time, my employer will not pay for this.

The proposal is the following.

* Implementation of OpenCL Code Generator.
** Abstract.
The project addresses generation of OpenCL kernels as OpenMP 4.0 target. 
Currently OpenMP 4.0 target implementation supports only host device as a 
target. I’m going to implement OpenCL kernels generator and extend libgomp with 
OpenCL routines.
During the project I'm going to reuse current (not finished) implementation of 
OpenCL generator from openacc-1_0-branch, refactor and implement it as OpenMP 
4.0 target plugin.

** Plan.
The project will consist of the following parts.

*** Kernels generator.
In this part I’m going to implement OpenCL C or OpenCL SPIR generator from 
GIMPLE representation as OpenMP 4.0 target plugin.

*** Libgomp extensions.
In this part I’m going to extend libgomp with OpenMP 4.0 plugin that allocates 
the memory at target device, maps the memory etc. Also I'm going to extend 
current implementation of OpenMP 4.0 target plugin API with routines to perform 
kernel compilation and enqueuing, if necessary.

** Schedule.
21 March - 18 May
Preparation:communicate with mentor, read libgomp source code, try submit some 
small patches to extend plugin API. Refactor code generator from 
openacc-1_0-branch.

19 May - 8 June
Coding to implement OpenCL runtime library: map clause, target update.

9 June - 22 June
Coding to implement kernels generator. Generate simple kernels: target.

23 June - 13 July
Generate complicated kernels: declare target.

14 July - 11 August
Detailed testing.

Is the proposal suitable?

-- 
Ilmir. 

Re: returning short-enum and truncate doesn't trigger conversion warning

[David Brown]

On 19/03/14 15:55, Paulo Matos wrote:
> 
> 
>> -Original Message-
>> From: David Brown [mailto:da...@westcontrol.com]
>> Sent: 19 March 2014 14:44
>> To: Paulo Matos; gcc@gcc.gnu.org
>> Subject: Re: returning short-enum and truncate doesn't trigger
>> conversion warning
>>
>> On 19/03/14 15:33, Paulo Matos wrote:
>>> Hi all,
>>>
>>> This is either a C standard subtlety or a bug in GCC.
>>
>> This is perfectly normal behaviour for C, and not a bug.  It is also a
>> topic for the gcc help list, rather than the development list.
>>
> 
> Apologies, but I submitted this to gcc devel because I do think it is a bug.

Usually the discovery of bugs gets discussed on the help list - fixes
for the bugs are an issue for the developers list.  And it is certainly
a "help" issue until we know you have found a bug.

> 
>>>
>>> enum xpto
>>> {
>>>   A = 0,
>>>   B = 1,
>>>   X = 512
>>> };
>>>
>>> extern void print (unsigned int);
>>>
>>> unsigned char bar (enum xpto a)
>>> {
>>>   print (sizeof (unsigned char));
>>>   print (sizeof (enum xpto));
>>>   return a;
>>> }
>>
>> The sizeof operator returns an integer of type size_t (typically the
>> same as unsigned int or unsigned long, depending on the platform
>> details).  But the compiler can see that the particular values in
>> question - 1 and 2 - can be converted to unsigned int without loss of
>> precision of changing the value.  Therefore no warning is giving.
>>
> 
> 512 cannot be converted to an unsigned char without loss of precision. 
> The prints are actually not relevant for the question. They were just used 
> for me to confirm the sizes of the types. 

Not only are the prints not relevant, but they hid the real issue - I
missed the point of your question!

Conversions involving enumerations are not listed in the documentation
for -Wconversion, but it would be nice to get a warning here.  Filing it
as an enhancement request seems reasonable.


> enum xpto
> {
>   A = 0,
>   B = 1,
>   X = 512
> };
> extern void print (unsigned int);
> 
> unsigned char bar (enum xpto a)
> {
>return a;
> }
> 
> Variable a could be 0, 1 or 512. In case of the latter there is loss of 
> precision but still no warning.
>  
>>>
>>> $ ~/work/tmp/GCC/builds/gcc-trunk/gcc/cc1 -O2 test.c -Wall
>>> -Wconversion --short-enums -quiet
>>> test.c: In function 'foo':
>>> test.c:3:3: warning: conversion to 'short unsigned int' from
>> 'unsigned int' may alter its value [-Wconversion]
>>>return a;
>>>^
>>>
>>> I was expecting a warning for bar as well since sizeof unsigned char
>> is 1 and sizeof enum xpto is 2, therefore the value is truncated but
>> no warning is issued.
>>>
>>> Shall I open a PR?
>>>
>>> Paulo Matos
>>>
>>
>>
> 

RE: returning short-enum and truncate doesn't trigger conversion warning

[Paulo Matos]

> -Original Message-
> From: David Brown [mailto:da...@westcontrol.com]
> Sent: 19 March 2014 15:47
> To: Paulo Matos; gcc@gcc.gnu.org
> Subject: Re: returning short-enum and truncate doesn't trigger
> conversion warning
> 
> 
> Usually the discovery of bugs gets discussed on the help list - fixes
> for the bugs are an issue for the developers list.  And it is
> certainly a "help" issue until we know you have found a bug.
>

Sure, I will make sure I submit these questions to gcc-help first.
 
> >
> >>>
> >>> enum xpto
> >>> {
> >>>   A = 0,
> >>>   B = 1,
> >>>   X = 512
> >>> };
> >>>
> >>> extern void print (unsigned int);
> >>>
> >>> unsigned char bar (enum xpto a)
> >>> {
> >>>   print (sizeof (unsigned char));
> >>>   print (sizeof (enum xpto));
> >>>   return a;
> >>> }
> >>
> >> The sizeof operator returns an integer of type size_t (typically
> the
> >> same as unsigned int or unsigned long, depending on the platform
> >> details).  But the compiler can see that the particular values in
> >> question - 1 and 2 - can be converted to unsigned int without loss
> of
> >> precision of changing the value.  Therefore no warning is giving.
> >>
> >
> > 512 cannot be converted to an unsigned char without loss of
> precision.
> > The prints are actually not relevant for the question. They were
> just used for me to confirm the sizes of the types.
> 
> Not only are the prints not relevant, but they hid the real issue - I
> missed the point of your question!
> 
> Conversions involving enumerations are not listed in the documentation
> for -Wconversion, but it would be nice to get a warning here.  Filing
> it as an enhancement request seems reasonable.
> 

Will report as an enhancement.

Thanks,

Paulo Matos

libgcc/config.host pattern question

[Joel Sherrill]

Hi

I tracked down a bug in building v850-rtems to a place in libgcc/config.host
where the code setting tmake_file did not append, it overwrote the previous
value. This caused v850-rtems to throw away the previous setting which
adding the newlib/sys/rtems/* directories to the include path.

diff --git a/libgcc/config.host b/libgcc/config.host
index bdc725f..f8f74cc 100644
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -1195,7 +1195,7 @@ tilepro*-*-linux*)
md_unwind_header=tilepro/linux-unwind.h
 ;;
 v850*-*-*)
-   tmake_file="v850/t-v850 t-fdpbit"
+   tmake_file="${tmake_file} v850/t-v850 t-fdpbit"
;;
 vax-*-linux*)
tmake_file="$tmake_file vax/t-linux"

I see other places in this case statement where tmake_file is reset. Is
this OK?
Should be be added to all the time when the pattern is CPU*-*-*? all the
time?

On a style inconsistency note, I see that some stanzas use $tmake_file
while
most use ${tmake_file}. Is there a rule? Personally I like having {} and
most
appear to have it.

Feedback appreciated.

-- 
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

Re: [GSoC 2014] Proposal: OpenCL Code Generator

[Maxim Kuvyrkov]

On Mar 20, 2014, at 4:02 AM, Ilmir Usmanov  wrote:

> Hi all!
> 
> My name is Ilmir Usmanov and I'm a student of Moscow Institute of Physics and 
> Technology.
> Also I'm implementing OpenACC 1.0 in gomp4 branch as an employee of Samsung 
> R&D Institute Russia (SRR). My research interests are connected with creating 
> OpenCL Code Generator. So I'd like to participate GSoC 2014 with project 
> called "OpenCL Code Generator" as an independent student. I will do the 
> project during my free time, my employer will not pay for this.

I do not think you will qualify as a student for the GSoC program.  Students 
are expected to work close to full-time during summer break and have GSoC as 
their main priority.  With your employment obligation I don't think you will be 
able to commit to your GSoC project at that level.

If I am wrong in my assumptions above, and you can commit to the GSoC project 
being your first priority for the summer months, please apply with your 
proposal on the GSoC website.  There is very little time left, so move fast.

Thank you,

--
Maxim Kuvyrkov
www.linaro.org

Re: [GSoC 2014] Proposal: OpenCL Code Generator

[Thomas Schwinge]

Hi Ilmir!

On Wed, 19 Mar 2014 19:02:11 +0400, Ilmir Usmanov  wrote:
> My name is Ilmir Usmanov and I'm a student of Moscow Institute of Physics and 
> Technology.
> Also I'm implementing OpenACC 1.0 in gomp4 branch as an employee of Samsung 
> R&D Institute Russia (SRR). My research interests are connected with creating 
> OpenCL Code Generator. So I'd like to participate GSoC 2014 with project 
> called "OpenCL Code Generator" as an independent student. I will do the 
> project during my free time, my employer will not pay for this.

How much time would you be able to allocate for working on the GSoC
project?  Per
,
»you should expect your project to be your primary focus this summer«.


> The proposal is the following.
> 
> * Implementation of OpenCL Code Generator.
> ** Abstract.
> The project addresses generation of OpenCL kernels as OpenMP 4.0 target. 
> Currently OpenMP 4.0 target implementation supports only host device as a 
> target. I’m going to implement OpenCL kernels generator and extend libgomp 
> with OpenCL routines.
> During the project I'm going to reuse current (not finished) implementation 
> of OpenCL generator from openacc-1_0-branch, refactor and implement it as 
> OpenMP 4.0 target plugin.

Specifically an »OpenMP 4.0 target plugin«, or generally a libgomp
plugin, so this would benefit both OpenACC and OpenMP, I assume?

> ** Plan.
> The project will consist of the following parts.
> 
> *** Kernels generator.
> In this part I’m going to implement OpenCL C or OpenCL SPIR generator from 
> GIMPLE representation as OpenMP 4.0 target plugin.
> 
> *** Libgomp extensions.
> In this part I’m going to extend libgomp with OpenMP 4.0 plugin that 
> allocates the memory at target device, maps the memory etc. Also I'm going to 
> extend current implementation of OpenMP 4.0 target plugin API with routines 
> to perform kernel compilation and enqueuing, if necessary.
> 
> ** Schedule.
> 21 March - 18 May
> Preparation:communicate with mentor, read libgomp source code, try submit 
> some small patches to extend plugin API. Refactor code generator from 
> openacc-1_0-branch.
> 
> 19 May - 8 June
> Coding to implement OpenCL runtime library: map clause, target update.
> 
> 9 June - 22 June
> Coding to implement kernels generator. Generate simple kernels: target.
> 
> 23 June - 13 July
> Generate complicated kernels: declare target.
> 
> 14 July - 11 August
> Detailed testing.
> 
> Is the proposal suitable?

Generally, such a project does appear suitable as a GSoC project, and you
should certainly file it on the GSoC site before the deadline on Friday,
so that it can be considered there.


Grüße,
 Thomas


pgpASgy3_H_Vi.pgp
Description: PGP signature

Re: Integration of ISL code generator into Graphite

[Tobias Grosser]

On 03/14/2014 09:18 PM, Roman Gareev wrote:

Dear gcc contributors,

I am going to try to participate in Google Summer of Code 2014. My project
is "Integration of ISL code generator into Graphite".

My proposal can be found at on the following link
https://drive.google.com/file/d/0B2Wloo-931AoTWlkMzRobmZKT1U/edit?usp=sharing.
I would be very grateful for your comments, feedback and ideas about
its
improvement.


Hi Roman,

sorry for the delay. The proposal looks already very promising. Here 
some more comments:


- Graphite does not any more support CLooG-PPL. This part of software is 
history. No need to talk about it in the proposal. We currently have 
CLooG-isl and want to replace it by the isl internal ast generator.


3) Benefits

- We currently do not have license issues with cloog-isl. So no need to 
talk about them.


- Users currently do not need to choose between CLooG with PPL and isl
  backend. The PPL backend is not supported any more


Actual new benefits:

- Support for unrolling, full/partial tile separation, as well as 
fine-grained code size adjustments


- In unreleased isl 0.13.0, support for compute out feature

- Improved code generation quality


4)

- CLooG is not only meant to generate C code. Using the clasts is a 
supported and direct way to use CLooG, as it is CLooG's library interface.


- "New internal representaion will be generated by ISL. Its structure is 
planned to be similar to the CLAST tree, but can be changed ..."


What does this  mean? The isl_ast representation is already defined. Are 
you saying that isl may generate an ast that is different in structure 
to the clast tree currently generated? Or are you saying we

still need to define the isl_ast and its nodes itself?

- "can be union" -> "can be the union"

4)

- It is great that you schedule explicit time to get familiar with
  the libraries and to do testing and bug fixing.

However, to get familiar, it would be nice to list a couple of small
projects/steps that you can use for this. E.g. in the first week
you could already generate an isl_build and an isl_union_map schedule,
pass it to the isl code generation and dump the resulting AST
to a file.

- "Designing of new internal format"

What kind of new format do you need to generate?

- "Code generation from internal form"

This is the whole project. You really should divide this into smaller 
steps. You could e.g. first just create a simple loop ignoring any basic 
blocks. You could then generate a simple loop with a single basic block. 
Then a loop with more complex ast expressions, then nested loops and 
ifs, ...


It would be very helpful if you could think about such steps and 
possibly an approach to ensure you systematically add all pieces of the 
code generation.


Also, it would be good to understand which parts of the code generation 
can be copied/shared with the exiting cloog based code generation and 
which parts need to be rewritten.



5)

gcc should bootstrap

6)

- Another nice to have would be to use the full/partial tile separation 
for the tiles generated by the isl scheduler.


cheers,
tobi

Re: Legitimize address after reload

[David Guillen]

Yep thanks,

As you guys pointed the problem was the improper handling of the
strict_p parameter.

Thanks!

2014-03-18 20:13 GMT+01:00 Richard Sandiford :
> Richard Sandiford  writes:
>> What DJ meant below was that you should reject all pseudo registers
>> if strict_p.  I.e. REG_P (foo) should be:
>>
>>REG_P (foo) && (!strict_p || REGNO_MODE_OK_FOR_BASE_P (foo, mode))
>
> sorry:
>
>   REG_P (foo) && (!strict_p || REGNO_MODE_OK_FOR_BASE_P (REGNO (foo), mode))
>
>> where REGNO_MODE_OK_FOR_BASE_P should only accept hard registers and
>> where "mode" is the mode of the memory being accessed.
>>
>> Thanks,
>> Richard

Spill registers not available

[David Guillen]

Hello!

As I stated on other emails I'm writing a backend. I'm facing a
problem regarding register modes.
The thing is: I don't know how to handle non-SI modes. I've read many
backends for different arches but I don't really get it, sorry.

In my case I've started with a x86 backend. This arch has 4
byte-accessible regs, therefore I implemented the macro
HARD_REGNO_MODE_OK to return false for those non QImode accessible
regs (in QImode of course).

This seems to work great with the inconvenient that sometimes I hit this error:

libstdc++-v3/include/bits/streambuf.tcc:110:5: error: could not find a
spill register
(insn 72 146 73 7 (parallel [
(set (mem:SI (plus:SI (reg/f:SI 7 %esp)
(const_int 4 [0x4])) [0 S4 A32])
(ashift:SI (subreg:SI (mem:QI (reg/v/f:SI 3 %ebx
[orig:42 __s ] [42]) [0 MEM[(const char_type &)__s_98]+0 S1 A8]) 0)
(const_int 24 [0x18])))
(clobber (reg:CC 10 eflags))
]) 
/home/david/uclibc/uclibc-buildroot-custom/output/build/host-gcc-final-gcc-4_7_3-release/build/i686-buildroot-linux-gnu/libstdc++-v3/include/bits/char_traits.h:287
7 {ashlsi3}
 (expr_list:REG_UNUSED (reg:CC 10 eflags)
(nil)))

Debugging it a little it seems that it tries to spill the memory
operand into a register, but it fails. I don't know why it picks a
non-byte accessible reg and therefore it fails (I guess because the
other ones are in use).

Another question would be: My ashift operator takes SI operands and
the memory operand is byte. Could I define an expand to set an SI reg
from a QI mem element by doing zero expansion (or sign extension)? And
how?

Thanks a lot!
David