This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [GSoC] questions about graphite_clast_to_gimple.c

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


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)

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)

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]