Re: CSE not combining equivalent expressions.
> Thanks. Another question I have is that, in this case, will the following > > http://gcc.gnu.org/wiki/Sign_Extension_Removal > > help in removal of the sign / zero extension ? First, it seems to me that in your case: (1) a = a | 1 /* a |= 1 */ (2) a = a | 1 /* a |= 1 */ the expressions "a | 1" in (1) and (2) are different as the "a" is not the same. So there is nothing to do for CSE. If the architecture has an instruction that does both the store and the zero extension, the zero extension instructions become redundant. The sign extension algorithm is supposed to catch such cases, but I suspect that in this simple case the regular combine is enough. Mircea
Re: CSE not combining equivalent expressions.
> Thanks. Another question I have is that, in this case, will the following > > http://gcc.gnu.org/wiki/Sign_Extension_Removal > > help in removal of the sign / zero extension ? First, it seems to me that in your case: (1) a = a | 1 /* a |= 1 */ (2) a = a | 1 /* a |= 1 */ the expressions "a | 1" in (1) and (2) are different as the "a" is not the same. So there is nothing to do for CSE. If the architecture has an instruction that does both the store and the zero extension, the zero extension instructions become redundant. The sign extension algorithm is supposed to catch such cases, but I suspect that in this simple case the regular combine is enough. Mircea
Re: CSE not combining equivalent expressions.
[EMAIL PROTECTED] (Richard Kenner) wrote on 17/01/2007 18:04:20: > > First, it seems to me that in your case: > > > > (1) a = a | 1 /* a |= 1 */ > > (2) a = a | 1 /* a |= 1 */ > > > > the expressions "a | 1" in (1) and (2) are different as the "a" > > is not the same. So there is nothing to do for CSE. > > It's not a CSE issue, but after (1), you know that the low-order bit of > "a" is a one, so that (2) is a no-op. Note that the similar >a &= ~1; >a &= ~1; > > we do catch in combine. > > It could also be caught by converting > >a = ((a | 1) | 1); > > into > >a = (a | (1 | 1)); > Yes, you are right if (1) and (2) are in the same basic block. But the initial example that started this thread looks like: a |= 1; if (*x) ... a }= 1; so (1) and (2) are in two separate basic blocks. I think that in this case combine doesn't work. Mircea
Re: Integration of ISL code generator into Graphite
Hi Roman, Congratulations. Advices: 1) it is thought that there is a correlation between the time spent for designing of code and the time need for debugging it - poor design could dramatically increase the debugging time. So don't rush to have some pieces of code running - it is very important to have before a clear picture of how these different pieces of code will fit together. 2) reuse code as much as possible - one source is of course Graphite - another source may be the PPCG compiler that uses isl AST to generate C/CUDA/OpenCL code. It is a source to source compiler, but still there are a lot of things that show you how to work with isl ast and may considerably help you. Mircea - Original Message - > From: "Roman Gareev" > To: "Mircea Namolaru" , "Tobias Grosser" > > Cc: "Albert Cohen" , gcc@gcc.gnu.org > Sent: Sunday, April 27, 2014 9:49:01 PM > Subject: Re: Integration of ISL code generator into Graphite > > Hi Mircea. > > Sorry, I've been missing for a while. Thank you for your ideas! I > agree that reusing of the existing code (especially code using > tree-SSA related information) is important for this project. I'm > considering the current code in graphite_clast_to_gimple.c, and want > to ask a few questions about it. I'll send them in a new message. > > > – > > > Cheers, Roman Gareev >
Re: Status of SEE and Autovectorization patches?
The patches for SEE have been committed today. The minor style corrections requested by you in the final review approval will be in a follow-up patch to be submitted the next week. Mircea
Re: Status of SEE and Autovectorization patches?
> That certainly does suggest a bug in the SEE patches. They needn't do > anything useful on IA32/AMD64, but they should presumably either (a) not > cause a bootstrap failure on these architectures, or (b) be disabled on > these architectures. Agree. I will check the bootstrapping on x86. (a) seems preferable but if not feasible in a short time frame, it will be (b). Mircea
Re: Status of SEE and Autovectorization patches?
> Given that this is more than a bootstrap problem with non-default flags, > but testsuite regressions for gfortran and SPEC failures on a primary > platform, I think this falls under GCC's 48 hour rule. This simply > formalizes your phrase "short time frame" above, and means that it you're > unlikely to come up with a solution to these problems in the next day > or two, that you/we should simply disable -fsee from being turned on by > default at -O3. I will disable -fsee for being turned on by default at -O3. In parallel I will work to see what exactly are the x86 problems. In my opinion the current x86 problems are due to some patterns difficult to figure out on PowerPC, and a few safety tests will suffice to fix then (i.e. to prevent the optimization to be done in these problematic cases). Mirea
Disabling -fsee at -O3
Committed according to http://gcc.gnu.org/ml/gcc/2006-05/msg00185.html Mircea 2006-05-07 Mircea Namolaru <[EMAIL PROTECTED]> * opts.c (flag_see): remove its setting at -O3. Index: opts.c === --- opts.c (revision 113518) +++ opts.c (working copy) @@ -592,7 +592,6 @@ flag_inline_functions = 1; flag_unswitch_loops = 1; flag_gcse_after_reload = 1; - flag_see = 1; } if (optimize < 2 || optimize_size)
Re: Disabling -fsee at -O3
> @item -fsee
> @opindex fsee
> Eliminates redundant extension instructions and move the non redundant
> ones to optimal placement using LCM.
> Enabled at level @option{-O3}.
>
> Would you mind adjusting this as well
Thanks. I've updated doc/invoke.texi correspondingly. Mircea
Re: Integration of ISL code generator into Graphite
Hi, First, I fully agree that integration of the ISL code generator into Graphite will be an important step forward for Graphite development. Regarding the implementation I have a question - why a new AST-like representation is needed ? It is not possible to generate the code directly from the ISL AST (with possible addition of new attributes/transformations) ? Regards, Mircea - Original Message - > From: "Roman Gareev" > To: gcc@gcc.gnu.org > Cc: "Tobias Grosser" , "Albert Cohen" > , "Mircea Namolaru" > > Sent: Friday, March 14, 2014 9:18:40 PM > Subject: Integration of ISL code generator into Graphite > > 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. > > P.S. Sorry for the copy of this message, the previous one was declined by > the MAILER-DAEMON. > > - > > Roman Gareev >
Re: Integration of ISL code generator into Graphite
Hi, 1. Maybe there is also an opportunity to improve the design of Graphite code generation, this will give you another benefit - code more robust, easier to maintain and extend. I suggest a design where the code generation from ISL AST is based on attributes (properties) of the ISL AST nodes. The computation of these attributes may requires several traversals of the AST tree, depending on the complexity of attribute that you need to compute. After you computed the required attributes, an additional traversal is used to generate the code. You may see CLOOG as using a single traversal of CLOOG AST where computation of attributes is interleaved with code generation. 2. The underlying design for polyhedral code generation in Graphite Polyhedral representation -> AST -> tree SSA. remains the same, but the CLOOG AST is replaced by the ISL AST. Semantically these two AST are rather similar both encoding the structure of the tree SSA code to be generated - take advantage of this and reuse as much as possible existent code. Due to time constraints reuse of existing code is a key point for this project. 3. A possible road map: - Identify the attributes used by CLOOG AST code generation and how they are used to generate tree-SSA code. - Compute the attributes found for the ISL AST (part of them may be already there under a different name). - Modify the current AST CLOOG generation part to be attribute driven - this will made possible its use by ISL AST (which as this stage has the required attributes). For the implementation you may start with a subset of attributes, perform these three steps for them - and then incrementally add new attributes. Hope that this attribute based approach is helpful for you. Regards, Mircea - Original Message - > From: "Tobias Grosser" > To: "Roman Gareev" > Cc: gcc@gcc.gnu.org, "Albert Cohen" , "Mircea > Namolaru" > Sent: Friday, March 21, 2014 12:51:26 PM > Subject: Re: Integration of ISL code generator into Graphite > > On 03/21/2014 12:04 PM, Roman Gareev wrote: > > Hi Tobias, > > > > thank you for all your comments! I've tried to consider them in the > > improved version of my proposal, which can be found at the following > > link > > https://drive.google.com/file/d/0B2Wloo-931AoeUlYOHhETVBvY3M/edit?usp=sharing > > . > > > >> - In unreleased isl 0.13.0, support for compute out feature > > > > I haven't found information about this feature and isl 0.13.0. Could > > you please give me a link to be referred to in the proposal? > > Section 1.4.1 of the isl manual documents the following functions: > > void isl_ctx_set_max_operations(isl_ctx *ctx, > unsigned long max_operations); > unsigned long isl_ctx_get_max_operations(isl_ctx *ctx); > void isl_ctx_reset_operations(isl_ctx *ctx); > > >> - Improved code generation quality > > > > I also haven't found code quality comparison between CLooG and ISL > > code generator. Do you mean, that ISL code generator can improve code > > quality with unrolling, full/partial tile separation, fine-grained > > code size adjustments? > > We have an unpublished paper on this. We should probably make this a > tech report at some point. > > >> - "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? > > > > I wanted to say that ISL will generate ISL AST from the polyhedral > > representation. This ISL AST (with pointers to original basic blocks > > instead of statments) will be internal representation for Graphite, > > that should be traversed and transformed into the GIMPLE CFG. I > > eliminated the mention of this internal representation in the improved > > version of the proposal. > > Good. > > I think this proposal is already very nice. I have some last comments in > case you want to really polish it: > > o 26-31 May: Get familiar with CLooG generation? > > Why is this necessary? > > > Also, for the remaining time-line, I think you could start working on > making this more detailed. > > Instead of having separate testing and fixing bug weeks, I think it > would be optimal to have for each weak one topic that you plan to finish > (including testing and fixing), as well as a brief idea how to do it. > You already have a good
Re: Integration of ISL code generator into Graphite
Hi, Look at the attributes as defining the interface provided by AST to the code generator. The code generator will work with any AST providing this interface. As you want to reuse the existing code, its structure affects the way in which you define this interface (i.e. the attributes). The most important attribute is the AST node type as currently TREE SSA code generation is driven by the type of the node. Other fields from clast struct are also good candidates for being considered attribute. But to copy all the fields from CLOOG AST into ISL AST (this will allow to preserve the current code) may not be a good solution. Instead a more flexible approach may be preferable where parts of the code are preserved, while other parts are restructured or completely rewritten. Determining this partition of the code is related with attributes definition. The types used in functions from graphite_clast_to_gimple.c provides a good criteria for performing this partition. Functions that use types related to tree SSA representation (CFG, induction variable etc), SCOP etc. are good candidates to be preserved or restructured. It depends of how you want to continue to access the information from CLAST CLOOG information in these functions - 1) continue to use the same fields from CLAST (but as fields of ISL AST). etc, then each field define an attribute, or 2) collapse multiple CLAST etc fields in a single attribute. In the later case the code computing this attribute need to be enclosed in a function/macro returning it. The attributes found may be already in the AST ISL but under a different name, or they need to be computed. Once the ISL AST tree is able to provide these attributes the functions accessing them could be preserved - the access to these attributes should be done via macro/functions/types to hide their implementation. Functions accessing only CLAST,CLOOG types are good candidates to be restructured or rewritten. This would be the underlying idea. Of course in practice a lot depends on the structure of the current code. Maybe start by analysing what types are used in the functions used by tree-SSA code generation. This will show you in what measure the code that you will want to keep (code using tree-SSA related types etc) is interleaved with code that you need to adopt or rewrite (code using CLAT, CLOOG data types). Depending on this, you may decide the relation between the ISL AST based code generation and CLOOG AST code generation in terms of preserve/restructure/rewrite. Another factor that needs to be taken into account is the time needed to stabilize the code (new written parts may take much longer time) Mircea - Original Message - > From: "Tobias Grosser" > To: "Mircea Namolaru" , "Roman Gareev" > > Cc: gcc@gcc.gnu.org, "Albert Cohen" > Sent: Monday, March 24, 2014 2:11:49 PM > Subject: Re: Integration of ISL code generator into Graphite > > On 03/24/2014 02:08 PM, Mircea Namolaru wrote: > > Hi, > > > > 1. Maybe there is also an opportunity to improve the design of Graphite > > code generation, this will give you another benefit - code more robust, > > easier > > to maintain and extend. > > > > I suggest a design where the code generation from ISL AST is based > > on attributes (properties) of the ISL AST nodes. > > Hi Mircea, > > could you give examples of the 'attributes' you are thinking of? > > Tobias > >
Re: Some thoughts about steerring commitee work
> As for C++, I think we need more OO language specific > optimizations. I don't know what the status of > devirtualizion which was reported on the previous > summit. Sorry for the late replay. The devirtualization is on hold. Currently GCC is lacking the necessary infrastructure needed by C++ interprocedural optimizations, like devirtualization. The appropriate infrastructure will be provided by LTO. I intend to incorporate the devirtualization in the LTO framework. Mircea infrastructure.
