Re: [Patch 0,1a] Improving effectiveness and generality of autovectorization using unified representation.
On Mon, Jun 13, 2016 at 12:56 PM, Sameera Deshpande wrote: > On Thursday 09 June 2016 05:45 PM, Richard Biener wrote: >> >> On Thu, Jun 9, 2016 at 10:54 AM, Richard Biener >> wrote: >>> >>> On Tue, Jun 7, 2016 at 3:59 PM, Sameera Deshpande >>> wrote: Hi Richard, This is with reference to our discussion at GNU Tools Cauldron 2015 regarding my talk titled "Improving the effectiveness and generality of GCC auto-vectorization." Further to our prototype implementation of the concept, we have started implementing this concept in GCC. We are following incremental model to add language support in our front-end, and corresponding back-end (for auto-vectorizer) will be added for feature completion. Looking at the complexity and scale of the project, we have divided this project into subtasks listed below, for ease of implementation, testing and review. 0. Add new pass to perform autovectorization using unified representation - Current GCC framework does not give complete overview of the loop to be vectorized : it either breaks the loop across body, or across iterations. Because of which these data structures can not be reused for our approach which gathers all the information of loop body at one place using primitive permute operations. Hence, define new data structures and populate them. 1. Add support for vectorization of LOAD/STORE instructions a. Create permute order tree for the loop with LOAD and STORE instructions for single or multi-dimensional arrays, aggregates within nested loops. b. Basic transformation phase to generate vectorized code for the primitive reorder tree generated at stage 1a using tree tiling algorithm. This phase handles code generation for SCATTER, GATHER, stridded memory accesses etc. along with permute instruction generation. 2. Implementation of k-arity promotion/reduction : The permute nodes within primitive reorder tree generated from input program can have any arity. However, the target can support maximum of arity = 2 in most of the cases. Hence, we need to promote or reduce the arity of permute order tree to enable successful tree tiling. 3. Vector size reduction : Depending upon the vector size for target, reduce vector size per statement and adjust the loop count for vectorized loop accordingly. 4. Support simple arithmetic operations : a. Add support for analyzing statements with simple arithmetic operations like +, -, *, / for vectorization, and create primitive reorder tree with compute_op. b. Generate vector code for primitive reorder tree generated at stage 4a using tree tiling algorithm - here support for complex patterns like multiply-add should be checked and appropriate instruction to be generated. 5. Support reduction operation : a. Add support for reduction operation analysis and primitive reorder tree generation. The reduction operation needs special handling, as the finish statement should COLLAPSE the temporary reduction vector TEMP_VAR into original reduction variable. b. The code generation for primitive reorder tree does not need any handling - as reduction tree is same as tree generated in 4a, with only difference that in 4a, the destination is MEMREF (because of STORE operation) and for reduction it is TEMP_VAR. At this stage, generate code for COLLAPSE node in finish statements. 6. Support other vectorizable statements like complex arithmetic operations, bitwise operations, type conversions etc. a. Add support for analysis and primitive reorder tree generation. b. Vector code generation. 7. Cost effective tree tiling algorithm : Till now, the tree tiling is happening without considering cost of computation. However, there can be multiple target instructions covering the tree - hence, instead of picking first matched largest instruction cover, select the instruction cover based on cost of instruction given in .md for the target. 8. Optimizations on created primitive reorder tree : This stage is open ended, and depending upon perf analysis, the scope of it can be defined. The current patch I have attached herewith handles stage 0 and 1a : Adds new pass to perform autovectorization using unified representation, defines new data structures to cater to this requirement and creates primitive reorder tree for LOAD/STORE instructions within the loop. The whole loop is represented using the ITER_NODE, which have information about - The preparatory statements for vectorization to be executed before entering the loop (like initialization of vectors, prepping for reduction
Re: _Bool and trap representations
Hi,
I modified Aexander's test case a bit, and found something
unexpected, which looks like a GCC-BUG to me:
cat test.c
#include
#include
#include
int main()
{
long double d0, d;
memcpy(&d0,
"\x00\x00\x00\x00\x00\x00\x00\x00\xff\x3f\x00\x00\x00\x00\x00\x00", sizeof d0);
// d = d0;
memcpy(&d, &d0, sizeof d0);
// if (memcmp(&d, &d0, sizeof d))
// abort();
printf("d = %Lf\n", d);
for (unsigned char *p = (unsigned char *)&d + sizeof d; p > (unsigned char
*)&d;)
printf("%02x ", *--p);
printf("\n");
}
// EOF
gcc -O3 test.c && ./a.out
d = 0.00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
but, when I un-comment the memcmp the test case shows the expected
result:
d = 0.00
00 00 00 00 00 00 3f ff 00 00 00 00 00 00 00 00
gcc-Version 7.0.0 20160613 (experimental) (GCC)
Would'nt you agree, that if we use memcpy it should be possible
to preserve denormalized or otherwise invalid bit patterns?
And why should the memcmp have an influence on the memcpy?
Bernd.
Re: _Bool and trap representations
On Wed, 15 Jun 2016, Bernd Edlinger wrote:
> Hi,
>
> I modified Aexander's test case a bit, and found something
> unexpected, which looks like a GCC-BUG to me:
>
> cat test.c
> #include
> #include
> #include
>
> int main()
> {
> long double d0, d;
>
> memcpy(&d0,
> "\x00\x00\x00\x00\x00\x00\x00\x00\xff\x3f\x00\x00\x00\x00\x00\x00", sizeof
> d0);
>
> // d = d0;
> memcpy(&d, &d0, sizeof d0);
> // if (memcmp(&d, &d0, sizeof d))
> // abort();
>
> printf("d = %Lf\n", d);
>
> for (unsigned char *p = (unsigned char *)&d + sizeof d; p > (unsigned char
> *)&d;)
> printf("%02x ", *--p);
> printf("\n");
> }
> // EOF
>
> gcc -O3 test.c && ./a.out
> d = 0.00
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>
> but, when I un-comment the memcmp the test case shows the expected
> result:
> d = 0.00
> 00 00 00 00 00 00 3f ff 00 00 00 00 00 00 00 00
>
> gcc-Version 7.0.0 20160613 (experimental) (GCC)
>
>
> Would'nt you agree, that if we use memcpy it should be possible
> to preserve denormalized or otherwise invalid bit patterns?
> And why should the memcmp have an influence on the memcpy?
I think this is PR71522 which I already fixed on trunk. memcmp
takes the address of the var and by doing that inhibits the broken
transform.
Richard.
where is the definition of struct gcc_options?
Hello, All I am reading the source of gcc(version 4.8.2), there is a important symbol 'global_options' whose type is struct gcc_options in cc1' entry function toplev_main(). I have build the gcc with make -g -O0, in gdb use ptype i can get the content of struct gcc_options, but in vim I cannot find its definition. $ ctags -R/ cscope -R And other symbol jump is correct, just struct gcc_options. Did I missing something? thx -- 业精于勤,荒于嬉.
Re: where is the definition of struct gcc_options?
On Wed, Jun 15, 2016 at 7:00 AM, zet wrote: > > I am reading the source of gcc(version 4.8.2), there is a important > symbol 'global_options' whose type is struct gcc_options > in cc1' entry function toplev_main(). > > I have build the gcc with make -g -O0, in gdb use ptype i can get the > content of struct gcc_options, > but in vim I cannot find its definition. > > $ ctags -R/ cscope -R > > And other symbol jump is correct, just struct gcc_options. > Did I missing something? It's in a generated file. Look at gcc/options.h in your build directory. There are many generated files in the GCC build. Ian
Re: _Bool and trap representations
There has been quite a bit of discussion among the committee on this subject lately (the last part is the subject of DR #451, though it's discussed in the context of uninitialized objects with indeterminate values). Are there notes from these discussions or something? Notes from discussions during committee meetings are in the meeting minutes that are posted along with other committee documents on the public site. Those that relate to aspects of defect reports are usually captured in the Committee Discussion and Committee Response to the DR. Other than that, committee discussions that take place on the committee mailing list (such as the recent ones on this topic) are archived for reference of committee members (unlike C++, the C archives are not intended to be open to the public). Martin
gcc-4.9-20160615 is now available
Snapshot gcc-4.9-20160615 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20160615/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.9 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_9-branch revision 237497 You'll find: gcc-4.9-20160615.tar.bz2 Complete GCC MD5=6e40408c735030024ca47752a5868ca6 SHA1=3e738f5c7a735b5d73f19ded18aa79c5bebf4c7a Diffs from 4.9-20160608 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.9 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: JonY appointed Cygwin and mingw-w64 maintainer
On 6/14/2016 03:07, David Edelsohn wrote: > I am pleased to announce that the GCC Steering Committee has > appointed Jon Y as Cygwin and mingw-w64 maintainer. > > Please join me in congratulating Jon on his new role. > Jon, please update your listing in the MAINTAINERS file. > > Happy hacking! > David > Updated MAINTAINERS file, thanks all! signature.asc Description: OpenPGP digital signature
