On 27/04/2014 21:52, Roman Gareev wrote:
Hi Tobias,
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
coretypes.h?
gcc/basic-block.h
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
high priority).
3. Why doesn't clast_guard have “else” statements?
CLooG does not compute else statements. Instead of having
if (i > 0)
...
else
...
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:
if (executeNewCode)
newly_generated_code
else
old_code
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
old code.
Tobias
