This is the mail archive of the gcc-patches@gcc.gnu.org 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: Resolving an issue of bootstrap failure from vectorization.


You found the root cause of the bootstrap profile with vectorizer
turned on, but the patch does not look correct to me. The sorting
needs to make sure accesses with the same (base, size, offset, step,
r_w_kind) are placed together (see how the sorted array is used to
build the interleaving chain).

Using UIDs in the comparison is fine (as long as the relative order of
UIDs do not change (when -g is flipped on/off)).

David

On Tue, Jul 9, 2013 at 1:55 PM, Cong Hou <congh@google.com> wrote:
> Repost to gcc-patch@gcc.gnu.org.
>
>
> ---------- Forwarded message ----------
> From: Cong Hou <congh@google.com>
> Date: Tue, Jul 9, 2013 at 1:10 PM
> Subject: Resolving an issue of bootstrap failure from vectorization.
> To: gcc@gcc.gnu.org
> Cc: David Li <davidxl@google.com>
>
>
> Hi
>
> My name is Cong Hou, and I am a Noogler working in the compiler
> optimization team at Google.
>
> When we were trying moving the vectorization from O3 to O2 in GCC 4.9,
> we met a bootstrap failure from comparison between stage 2&3. This
> failure is caused by a potential bug in GCC as stated below.
>
> In the file tree-vect-data-refs.c, there is a qsort() function call
> which sorts a group of data references using a comparison function
> called "dr_group_sort_cmp()". In this function, the iterative hash
> values of tree nodes are used for comparisons. For a declaration tree
> node, its UID participates in the calculation of the hash value.
> However, a specific declaration may have different UIDs whether the
> debug information is switched on/off. In consequence, the results of
> comparisons may vary in stage 2&3 during bootstrapping.
>
> As a solution, I think we need a function to compare two tree nodes
> that does not rely on UIDs. An apparent idea is comparing the tree
> code first, and if they have the same tree code, then compare their
> subnodes recursively. To resolve the issue we have now, I just
> composed a very basic comparison function which only compares tree
> codes, and this patch can make the bootstrap get passed. I have
> attached the patch here.
>
> I am wondering if this is a valid solution and appreciate if someone
> could give me any feedback.
>
>
> Thank you!
>
>
> Cong


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