This is the mail archive of the
mailing list for the GCC project.
Re: [GSoC] questions about graphite_clast_to_gimple.c
- From: Tobias Grosser <tobias at grosser dot es>
- To: Roman Gareev <gareevroman at gmail dot com>, Mircea Namolaru <mircea dot namolaru at inria dot fr>
- Cc: gcc at gcc dot gnu dot org
- Date: Mon, 28 Apr 2014 08:14:54 +0200
- Subject: Re: [GSoC] questions about graphite_clast_to_gimple.c
- Authentication-results: sourceware.org; auth=none
- References: <CABGF_gfsbEmL7FODBF9dmLMFFtRbpqBk3Nm54P9e0WOYS1bGSw at mail dot gmail dot com>
On 27/04/2014 21:52, Roman Gareev wrote:
I'm considering the current code in graphite_clast_to_gimple.c, and
want to ask a few questions about it.
1. Where can I find the definitions of basic_block_def and edge from
2. Why are recompute_all_dominators() and graphite_verify() called
before initialization of if_region in gloog? Does it happen just in
case (since the SSA form hasn't been modified)?
I am unsure. Somewhere in the back of my head, I remember that some
preceding passes did not update the dominators properly and this caused
issues in graphite. This may or may not be true today, so verifying this
might be a good thing at some point. We could replace this with an
assert that verifies the dominator information and run a couple of tests
with this. Maybe this gives us a test case. (So this is probably not
3. Why doesn't clast_guard have âelseâ statements?
CLooG does not compute else statements. Instead of having
if (i > 0)
it will emit
if (i > 0)
if (i <= 0)
The isl code generation can emit else statements to generate the more
efficient first code.
4. Why is compute_bounds_for_param (it's from
add_names_to_union_domain) called after save_clast_name_index?
No idea. This looks suspicious. Good catch.
A comment on all this 'type_for_clast_name' infrastructure. It tries to
address the problem of what type to use when code generating loop ivs or
index expressions. However, it does it very poorly and has little chance
to be correct. For the new code generation
we want to do this right. This means, we do not try to add any
infrastructure ourselves to try to derive the correct types. Instead, we
ask the isl code generation for the minimal bitwidth/signedness
required. This will give us a precise and always correct answer. I have
a preliminary patch in my repo. We can look at this later on. To start
with, I propose to always go for a signed 64 (or for testing even 128
bit type). This has proven to be very robust.
5. I've considered practically all the code of a CLAST generation
through GLooG and started consideration of translate_clast. However, I
don't understand the idea behind if_region creation. Do you know
something about it?
The idea is that we generate a construct:
In the trivial case executeNewCode is true and gcc will dead code
eliminate old_code. However, we can also replace executeNewCode with a
run-time checking e.g. for the absence of aliasing or other assumptions
we take. In this case, the newly generated code will only be executed if
our assumptions hold. Otherwise, we will automatically fall back to the