Re: How to access structure information from "pass_vectorize"
On Sun, Jan 19, 2014 at 6:01 PM, Swati Rathi wrote: > We are writing a GIMPLE pass and would like to use some information computed > in > pass_vectorize. However, we are not able to use the data structures which > gets populated in pass_vectorize > because the information is not made available across passes. > > In particular, we wish to access the structures "stmt_vec_info" and > "data_reference". > > How do we access this information? Should we invoke pass_vectorize as a > sub-pass of our pass? Should > we explicitly call the execute function of pass_vectorize in our pass? Or > should we modify pass_vectorize > code and make a deep copy in a global variable? Is there any other way of > getting this information? It really depends on what kind of information you want to access. You can re-compute things in your pass, or you can make your pass part of the vectorizer (thus, modify the vectorizer pass). In particular data_reference is just what the data-reference analysis usable from any pass (tree-data-ref.h) produces. But without more information on what information exactly you want to access (and where - where is your pass placed compared to the vectorizer?) it is hard to suggest anything. Richard.
Re: How to access structure information from "pass_vectorize"
On Monday 20 January 2014 02:20 PM, Richard Biener wrote:
On Sun, Jan 19, 2014 at 6:01 PM, Swati Rathi wrote:
We are writing a GIMPLE pass and would like to use some information computed
in
pass_vectorize. However, we are not able to use the data structures which
gets populated in pass_vectorize
because the information is not made available across passes.
In particular, we wish to access the structures "stmt_vec_info" and
"data_reference".
How do we access this information? Should we invoke pass_vectorize as a
sub-pass of our pass? Should
we explicitly call the execute function of pass_vectorize in our pass? Or
should we modify pass_vectorize
code and make a deep copy in a global variable? Is there any other way of
getting this information?
It really depends on what kind of information you want to access. You can
re-compute things in your pass, or you can make your pass part of the
vectorizer (thus, modify the vectorizer pass). In particular data_reference
is just what the data-reference analysis usable from any pass (tree-data-ref.h)
produces.
But without more information on what information exactly you want to access
(and where - where is your pass placed compared to the vectorizer?) it is
hard to suggest anything.
Richard.
We wish to access the chain of recurrence (chrecs) which is being
populated in the below structure.
struct indices
{
/* The object. */
tree base_object;
/* A list of chrecs. Access functions of the indices. */
VEC(tree,heap) *access_fns;
/* Whether BASE_OBJECT is an access representing the whole object
or whether the access could not be constrained. */
bool unconstrained_base;
};
Our pass is placed after "pass_ipa_pta".
However, we even tried placing the pass after pass_vectorize to access
this information.
Can we use the chain of recurrence computed by the pass_vectorize or do
we have to recompute it?
Is there any other pass which is also computing this information and can
we access it?
Re: How to access structure information from "pass_vectorize"
On Mon, Jan 20, 2014 at 11:17 AM, Swati Rathi wrote:
> On Monday 20 January 2014 02:20 PM, Richard Biener wrote:
>>
>> On Sun, Jan 19, 2014 at 6:01 PM, Swati Rathi
>> wrote:
>>>
>>> We are writing a GIMPLE pass and would like to use some information
>>> computed
>>> in
>>> pass_vectorize. However, we are not able to use the data structures which
>>> gets populated in pass_vectorize
>>> because the information is not made available across passes.
>>>
>>> In particular, we wish to access the structures "stmt_vec_info" and
>>> "data_reference".
>>>
>>> How do we access this information? Should we invoke pass_vectorize as a
>>> sub-pass of our pass? Should
>>> we explicitly call the execute function of pass_vectorize in our pass? Or
>>> should we modify pass_vectorize
>>> code and make a deep copy in a global variable? Is there any other way of
>>> getting this information?
>>
>> It really depends on what kind of information you want to access. You can
>> re-compute things in your pass, or you can make your pass part of the
>> vectorizer (thus, modify the vectorizer pass). In particular
>> data_reference
>> is just what the data-reference analysis usable from any pass
>> (tree-data-ref.h)
>> produces.
>>
>> But without more information on what information exactly you want to
>> access
>> (and where - where is your pass placed compared to the vectorizer?) it is
>> hard to suggest anything.
>>
>> Richard.
>
>
> We wish to access the chain of recurrence (chrecs) which is being populated
> in the below structure.
>
> struct indices
> {
> /* The object. */
> tree base_object;
>
> /* A list of chrecs. Access functions of the indices. */
> VEC(tree,heap) *access_fns;
>
> /* Whether BASE_OBJECT is an access representing the whole object
> or whether the access could not be constrained. */
> bool unconstrained_base;
> };
>
>
> Our pass is placed after "pass_ipa_pta".
> However, we even tried placing the pass after pass_vectorize to access this
> information.
>
> Can we use the chain of recurrence computed by the pass_vectorize or do we
> have to recompute it?
> Is there any other pass which is also computing this information and can we
> access it?
You can and should simply re-compute them with
compute_data_dependences_for_loop.
Richard.
>
Rogue SUBREG
I'm looking into http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58901
and trying to find where the following rtx is being generated:
(subreg:HI (mem/u/c:SI (plus:SI (mult:SI (reg/v:SI 0 %r0 [orig:77 count ] [77])
(const_int 4 [0x4]))
(symbol_ref:SI ("DECPOWERS") [flags 0x40] )) [3 DECPOWERS S4 A32]) 0)
The memory reference causes mode_dependent_address_p to return true.
Note
I added code to gen_rtx_SUBREG to detect a MEM with a mode dependent
address and print it but it never triggers. I also added code before
gen_rtx_raw_SUBREG as well and those don't trigger as well.
alter_subreg can't fix the subreg since it has a mode dependent address.
I think this is happening in reload since 213r.ira I find:
(insn 225 223 226 46 (set (reg:SI 137)
(mem/u:SI (plus:SI (mult:SI (reg/v:SI 77 [ count ])
(const_int 4 [0x4]))
(symbol_ref:SI ("DECPOWERS") [flags 0x40] )) [3 DECPOWERS S4 A32])) ../../gcc-4.8.2/libdecnumber/decNumber.c
:7183 12 {movsi_2}
(expr_list:REG_EQUIV (mem/u:SI (plus:SI (mult:SI (reg/v:SI 77 [ count ])
(const_int 4 [0x4]))
(symbol_ref:SI ("DECPOWERS") [flags 0x40] )) [3 DECPOWERS S4 A32])
(nil)))
(insn 226 225 227 46 (set (mem:HI (reg/v/f:SI 78 [ sup ]) [2 *sup_105+0 S2 A16])
(plus:HI (subreg:HI (reg:SI 137) 0)
(const_int -1 [0x]))) ../../gcc-4.8.2/libdecnumber/d
ecNumber.c:7183 48 {addhi3}
(expr_list:REG_DEAD (reg:SI 137)
(nil)))
That's fine if pseudo 137 gets instantiated to a register.
In 214r.reload that becomes:
(insn 226 225 227 46 (set (mem:HI (reg/v/f:SI 1 %r1 [orig:78 sup ] [78]) [2 *sup
_105+0 S2 A16])
(plus:HI (subreg:HI (mem/u/c:SI (plus:SI (mult:SI (reg/v:SI 0 %r0 [orig:
77 count ] [77])
(const_int 4 [0x4]))
(symbol_ref:SI ("DECPOWERS") [flags 0x40] )) [3 DECPOWERS S4 A32]) 0)
(const_int -1 [0x]))) ../../gcc-4.8.2/libdecnumber/d
ecNumber.c:7183 48 {addhi3}
(nil))
which is now invalid due to use of a mode dependent address. So who's
doing this? I'm guessing it's combine but that code is opaque to me.
Any ideas where to look?
Re: Rogue SUBREG
> I think this is happening in reload since 213r.ira I find:
>
> (insn 225 223 226 46 (set (reg:SI 137)
> (mem/u:SI (plus:SI (mult:SI (reg/v:SI 77 [ count ])
> (const_int 4 [0x4]))
> (symbol_ref:SI ("DECPOWERS") [flags 0x40] 0x7f7ff63b3 5f0 DECPOWERS>)) [3 DECPOWERS S4 A32]))
> ../../gcc-4.8.2/libdecnumber/decNumber.c
> :7183 12 {movsi_2}
>
> (expr_list:REG_EQUIV (mem/u:SI (plus:SI (mult:SI (reg/v:SI 77 [ count
> ]) (const_int 4 [0x4]))
> (symbol_ref:SI ("DECPOWERS") [flags 0x40] 0x7f7ff63b3 5f0 DECPOWERS>)) [3 DECPOWERS S4 A32])
> (nil)))
> (insn 226 225 227 46 (set (mem:HI (reg/v/f:SI 78 [ sup ]) [2 *sup_105+0 S2
> A16]) (plus:HI (subreg:HI (reg:SI 137) 0)
> (const_int -1 [0x])))
> ../../gcc-4.8.2/libdecnumber/d ecNumber.c:7183 48 {addhi3}
> (expr_list:REG_DEAD (reg:SI 137)
> (nil)))
>
> That's fine if pseudo 137 gets instantiated to a register.
>
> In 214r.reload that becomes:
>
> (insn 226 225 227 46 (set (mem:HI (reg/v/f:SI 1 %r1 [orig:78 sup ] [78]) [2
> *sup _105+0 S2 A16])
> (plus:HI (subreg:HI (mem/u/c:SI (plus:SI (mult:SI (reg/v:SI 0 %r0
> [orig: 77 count ] [77])
> (const_int 4 [0x4]))
> (symbol_ref:SI ("DECPOWERS") [flags 0x40] 0x7 f7ff63b35f0 DECPOWERS>)) [3 DECPOWERS S4 A32]) 0)
> (const_int -1 [0x])))
> ../../gcc-4.8.2/libdecnumber/d ecNumber.c:7183 48 {addhi3}
> (nil))
>
> which is now invalid due to use of a mode dependent address. So who's
> doing this? I'm guessing it's combine but that code is opaque to me.
If it appears in .reload, then it's reload and not combine. Most likely the
MEM is the equivalent memory location of (reg:SI 137) thanks to the REG_EQUIV
note and gets substituted for it at the end of reload; that's done in place so
gen_rtx_SUBREG is not called. Try and see whether find_reloads_subreg_address
is invoked on it and, if so, what happens then.
--
Eric Botcazou
