On 4/4/19, Martin Jambor <mjam...@suse.cz> wrote:
> Hi,
>
> On Wed, Apr 03 2019, sameeran joshi wrote:
>> On 4/3/19, Martin Jambor <mjam...@suse.cz> wrote:
>>> Hello Joshi,
>>>
>>> On Mon, Apr 01 2019, sameeran joshi wrote:
>>>> HI,
>>>> Discussing the project with Andi, I have drafted a proposal, please
>>>> review and suggest
>>>> necessary changes.
>>>> If some OpenMP experts from GCC have some ideas or changes please
>>>> suggest.
>>>>
>>>> https://docs.google.com/document/d/1axElw-I5pTwcjI4iMle5NhLeRCcshIjH5ZHm3GGwsZU/edit?usp=sharing
>>>
>>> I will leave most of the evaluation on Andi (and assume he likes the
>>> proposal, by the way). However, I have read the proposal, I like it and
>>> I consider it very useful but also possibly quite ambitious. But we can
>>> adjust expectations as we go forward.
>>>
>>> Please consider fixing some of the formatting in the document,
>>> especially of the code snippets, sometimes they are a bit difficult to
>>
>> Thanks for pointing it, I have indented them.
>
> Great, it indeed is now much better.
>
>>
>>> read without any indentation. That may be also the reason why I don't
>>> quite understand what is the relationship of omp tasks and loops or
>>> uninitialized local arrays.
>>
>> I have removed the location to insert for OMP tasks at 'uninitialized
>> local array initialization'.
>> Only kept it for as it was getting more complex.
>>
>> 1. while loops
>> 2. nested for loops
>
> OK.
>
>>
>> If you could suggest which constructs do you feel more ambitious?, so
>
> The one thing I am quite intrigued by is how exactly you will detect
> data races,
There could be 2 approaches to it:
1. Not changing the current generation grammar :
How?
//This is done after statement is generated and after fact analysis of
statement is done, inside Statement::make_random()
//whenever statement is generated, can set flag to indicate a data race in it.
check_and set_data_race_in_statement(){
1.retrieve write vars from current statement (Effect.h)
2.loop through all write vars and check is_shared(write_var)
if true
its a data race
set some flag to indicate
}
This labels each statement with a flag to indicate data race in the
statement, now after generation of a particular block, looping through
the statements and checking whether they have a data race,
if YES:(possible solutions )
1.Neglect the block for parallel region ( may not be
efficient as may neglect most of the blocks)
2. May be apply some synchronization constructs to the block.
if NO race:
good to go with the block to be parallel.
Andi suggested "that will be hard after the fact", But I found Csmith
doing some Fact analysis (DFA analysis) in it's code base.
Which I didn't explore during the previous project.
Will need some help to investigate about Fact Analysis (Fact*.h) which Csmith
already implements, also they maintain the current generation context
(CG_Context.h). As I think would solve most of the problems?
2. Decide before you generate the block that is parallel( a block
would be explicitly selected as a parallel block (based on
probability) ) and then avoid generating any data races. (Andi
suggested )
So, how do you avoid them?
e.g.
LHS OP EXPRESSION
Whenever a LHS variable is selected, care needs to be taken
it's not a shared variable.This avoids the data races during
generation itself.
But this approach restricts the generation grammar, so only
writes to local variables from that block will be present in the
block . Will this work?
The above function could now become something like
Statement::check_and_avoid_data_races_in_statement()
-----------------------------------------------------------------------------------------------
> but I assume a conservative but useful approach will not be
> too difficult to devise.
I feel the most time consuming and challenging part would be adding
the first extension, i.e the ' #pragma omp parallel' pragma.
Do you have more suggestions ?
>
>> I could work on it to modify them.
>
> Don't worry about the remark too much. The proposal looks solid.
>
> Martin
>
Thanks,
Sameeran Joshi
