This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH GCC][01/13]Introduce internal function IFN_LOOP_DIST_ALIAS
On June 27, 2017 4:27:17 PM GMT+02:00, "Bin.Cheng" <amker.cheng@gmail.com> wrote:
>On Tue, Jun 27, 2017 at 1:58 PM, Richard Biener
><richard.guenther@gmail.com> wrote:
>> On Fri, Jun 23, 2017 at 12:10 PM, Bin.Cheng <amker.cheng@gmail.com>
>wrote:
>>> On Mon, Jun 12, 2017 at 6:02 PM, Bin Cheng <Bin.Cheng@arm.com>
>wrote:
>>>> Hi,
>>>> I was asked by upstream to split the loop distribution patch into
>small ones.
>>>> It is hard because data structure and algorithm are closely coupled
>together.
>>>> Anyway, this is the patch series with smaller patches. Basically I
>tried to
>>>> separate data structure and bug-fix changes apart with one as the
>main patch.
>>>> Note I only made necessary code refactoring in order to separate
>patch, apart
>>>> from that, there is no change against the last version.
>>>>
>>>> This is the first patch introducing new internal function
>IFN_LOOP_DIST_ALIAS.
>>>> GCC will distribute loops under condition of this function call.
>>>>
>>>> Bootstrap and test on x86_64 and AArch64. Is it OK?
>>> Hi,
>>> I need to update this patch fixing an issue in
>>> vect_loop_dist_alias_call. The previous patch fails to find some
>>> IFN_LOOP_DIST_ALIAS calls.
>>>
>>> Bootstrap and test in series. Is it OK?
>>
>> So I wonder if we really need to track ldist_alias_id or if we can do
>sth
>Yes, it is needed because otherwise we probably falsely trying to
>search for IFN_LOOP_DIST_ALIAS for a normal (not from distribution)
>loop.
>
>> more "general", like tracking a copy_of or origin and then directly
>> go to nearest_common_dominator (loop->header, copy_of->header)
>> to find the controlling condition?
>I tend to not record any pointer in loop structure, it can easily go
>dangling for a across passes data structure.
I didn't mean to record a pointer, just rename your field and make it more general. The common dominator thing shod still work, no?
As far as memory usage
>is concerned. I actually don't need a whole integer to record the
>loop num. I can simply restrict number of distributions in one
>function to at most 256, and record such id in a char field in struct
>loop? Does this sounds better?
As said, tracking loop origin sounds useful anyway so I'd rather add and use that somehow.
>Thanks,
>bin
>>
>> That said "ldist_alias_id" is a bit too narrow of purpose to "waste"
>> an int inside struct loop? I'd set copy_of/origi in loop_version for
>example.
>> 'origin' would probably be better given the ldist cases aren't really
>> full "copies".
>>
>> fold_loop_dist_alias_call should re-use / rename
>fold_loop_vectorized_call
>> by just passing folded_value to it.
>>
>> Richard.
>>
>>> Thanks,
>>> bin
>>>>
>>>> Thanks,
>>>> bin
>>>> 2017-06-07 Bin Cheng <bin.cheng@arm.com>
>>>>
>>>> * cfgloop.h (struct loop): New field ldist_alias_id.
>>>> * cfgloopmanip.c (lv_adjust_loop_entry_edge): Comment
>change.
>>>> * internal-fn.c (expand_LOOP_DIST_ALIAS): New function.
>>>> * internal-fn.def (LOOP_DIST_ALIAS): New.
>>>> * tree-vectorizer.c (vect_loop_dist_alias_call): New
>function.
>>>> (fold_loop_dist_alias_call): New function.
>>>> (vectorize_loops): Fold IFN_LOOP_DIST_ALIAS call depending
>on
>>>> successful vectorization or not.