Re: vector alignment
On Tue, Apr 2, 2019 at 6:20 PM Martin Sebor wrote: > > GCC tries to align a vector on its natural boundary, i.e., that > given by its size, up to MAX_OBJECT_ALIGNMENT. Vectors that are > bigger than that are either silently [mis]aligned on that same > maximum boundary (PR 89798), silently truncated (and misaligned), > or cause an ICE (PR 89797). Compiling the following: > >__attribute__ ((vector_size (N))) char v; > >_Static_assert (sizeof (v) == N, "size"); >_Static_assert (__alignof__ (v) == N, "alignment"); > > with N set to 1LLU << I shows these failures: > >I < 29 succeeds >I < 31 fails alignment >I < 32 ICE >I >= 32 fails alignment and size > > Attribute aligned doesn't seem to have any effect on types or > variables declared with attribute vector_size. The alignment > set by the latter prevails. > > This happens no matter what scope the vector is defined in (i.e., > file or local). > > I have some questions: > > 1) Is there some reason to align vectors on the same boundary > as their size no matter how big it is? I can't find such > a requirement in the ABIs I looked at. Or would it be more > appropriate to align the big ones on the preferred boundary > for the target? For instance, does it make more sense to > align a 64KB vector on a 64KB boundary than on, say, > a 64-byte boundary (or some other boundary less than 64K?) I don't think there's a good reason. Instead I think that BIGGEST_ALIGNMENT is what we should go for as upper limit, anything bigger doesn't make sense (unless the user explicitely requests it). > 2) If not, is it then appropriate to underalign very large > vectors on a boundary less than their size? Yes. > 3) Should the aligned attribute not override the default vector > alignment? Yes, but doesn't it already? > I would like to think the answer to (1) is that vectors should > be aligned on the preferred boundary for the target/ABI. If > that's feasible, it should also obviate question (2). > > I believe the answer to (3) is yes. If not, GCC should issue > a warning that it doesn't honor the aligned attribute. > > Thanks > Martin
Re: GSOC Proposal
On Mon, 1 Apr 2019, nick wrote: > > > On 2019-04-01 9:47 a.m., Richard Biener wrote: > > On Mon, 1 Apr 2019, nick wrote: > > > >> Well I'm talking about the shared roots of this garbage collector core > >> state > >> data structure or just struct ggc_root_tab. > >> > >> But also this seems that this to be no longer shared globally if I'm not > >> mistaken > >> or this: > >> static vec extra_root_vec; > >> > >> Not sure after reading the code which is a bigger deal through so I wrote > >> my proposal not just asking which is a better issue for not being thread > >> safe. Sorry about that. > >> > >> As for the second question injection seems to not be the issue or outside > >> callers but just internal so phase 3 or step 3 would now be: > >> Find internal callers or users of x where x is one of the above rather > >> than injecting outside callers. Which answers my second question about > >> external callers being a issue still. > >> > >> Let me know which of the two is a better issue: > >> 1. struct ggc_root_tabs being shared > >> 2.static vec extra_root_vec; as a shared heap or > >> vector of root nodes for each type of allocation > >> > >> and I will gladly rewrite my proposal sections for that > >> as needs to be reedited. > > > > I don't think working on the garbage collector as a separate > > GSoC project is useful at this point. Doing locking around > > allocation seems like a good short-term solution and if that > > turns out to be a performance issue for the threaded part > > using per-thread freelists is likely an easy to deploy > > solution. > > > > Richard. > > > I agree but we were discussing this: > Or maybe a project to be more > explicit about regions of the code that assume that the garbage- > collector can't run within them?[3] (since the GC is state that would > be shared by the threads). The process of collecting garbage is not the only issue (and that very issue is easiest mitigated by collecting only at specific points - which is what we do - and have those be serializing points). The main issue is the underlying memory allocator (GCC uses memory that is garbage collected plus regular heap memory). > In addition I moved my paper back to our discussion about garbage collector > state with outside callers.Seems we really need to do something about > my wording as the idea of my project in a nutshell was to figure > out how to mark shared state by callers and inject it into the > garbage collector letting it known that the state was not shared between > threads or shared. Seems that was on the GSoc page and in our discussions the > issue > is marking outside code for shared state. If that's correct then my > wording of outside callers is incorrect it should have been shared > state between threads on outside callers to the garbage collector. > If the state is that in your wording above then great as I understand > where we are going and will gladly change my wording. I'm still not sure what you are shooting at, the above sentences do not make any sense to me. > Also freelists don't work here as the state is shared at the caller's > end which would need two major issues: > 1. Locking on nodes of the > freelists when two threads allocate at the same thing which can be a > problem if the shared state is shared a lot > 2. Locking allocation with > large numbers of callers can starve threads First of all allocating memory from the GC pool is not the main work of GIMPLE passes so simply serializing at allocation time might work out. Second free lists of course do work. What you'd do is have a fast path in allocation using a thread-local "free list" which you can allocate from without taking any lock. Maybe I should explain "free list" since that term doesn't make too much sense in a garbage collector world. What I'd do is when a client thread asks for memory of size N allocate M objects of that size but put M - 1 on the client thread local "free list" to be allocated lock-free from for the next M - 1 calls. Note that garbage collected memory objects are only handed out in fixed chunks (powers of two plus a few special sizes) so you'd have one "free list" per chunk size per thread. The collection itself (mark & sweep) would be fully serialized still (and not return to any threads local "free list"). ggc_free'd objects _might_ go to the threads "free list"s (yeah, we _do_ have ggc_free ...). As said, I don't see GC or the memory allocator as sth interesting to work on for parallelization until the basic setup works and it proves to be a bottleneck. > Seems that working on the garbage collector itself isn't the issue but > the callers as I just figured out as related to your state idea. Let me > know if that's correct and if the wording change I mentioned is fine > with you as that's the state it seems that needs to be changed. > Nick Richard. -- Richard Biener SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer, Mary Higgins, Sr
Re: GSoC Project Ideas
On Tue, Apr 2, 2019 at 1:43 AM Patrick Palka wrote: > > Hi Richard, Jakub and Martin, > > First of all I'm sorry for the very late reply, and I will be more > punctual with my replies from now on. > > On Fri, Mar 8, 2019 at 4:35 AM Richard Biener > wrote: > > > > On Thu, Mar 7, 2019 at 7:20 PM Martin Sebor wrote: > > > > > > On 3/4/19 6:17 AM, Richard Biener wrote: > > > > On Mon, Mar 4, 2019 at 1:23 PM Jakub Jelinek wrote: > > > >> > > > >> On Mon, Mar 04, 2019 at 01:13:29PM +0100, Richard Biener wrote: > > > >* Make TREE_NO_WARNING more fine-grained > > > > (inspired by comment #7 of PR74762 [3]) > > > >TREE_NO_WARNING is currently used as a catch-all marker that > > > > inhibits all > > > >warnings related to the marked expression. The problem with > > > > this is that > > > >if some warning routine sets the flag for its own purpose, > > > >then that later may inhibit another unrelated warning from > > > > firing, see for > > > >example PR74762. Implementing a more fine-grained mechanism > > > > for > > > >inhibiting particular warnings would eliminate such issues. > > > Might be interesting. You'd probably need to discuss the details > > > further. > > > >>> > > > >>> I guess an implementation could use TREE_NO_WARNING (or > > > >>> gimple_no_warning_p) > > > >>> as indicator that there's out-of-bad detail information which could > > > >>> be stored as > > > >>> a map keyed off either a location or a tree or gimple *. > > > >> > > > >> I guess on tree or gimple * is better, there would need to be some > > > >> hook for > > > >> copy_node/gimple_copy that would add the info for the new copy as well > > > >> if > > > >> the TREE_NO_WARNING or gimple_no_warning_p bit was set. Plus there > > > >> could be > > > >> some purging of this on the side information, e.g. once code is > > > >> handed over > > > >> from the FE to the middle-end (maybe do that only at free_lang_data > > > >> time), > > > >> for any warnings that are FE only there is no need to keep records in > > > >> the on > > > >> the side mapping that have info about those FE warnings only, as later > > > >> on > > > >> the FE warnings will not be reported anymore. > > > >> The implementation could be e.g. a hash map from tree/gimple * > > > >> (pointers) to > > > >> bitmaps of warning numbers, with some hash table to ensure that the > > > >> same > > > >> bitmap is used for all the spots that need to have the same set of > > > >> warnings > > > >> disabled. > > This design makes a lot of sense, thank you for this! > > > > > > > > > A possibly related project is to "defer" output of diagnostics until we > > > > know > > > > the stmt/expression we emit it for survived dead code elimination. > > > > Here there's > > > > the question what to key the diagnostic off and how to move it (that > > > > is, detect > > > > if the code causing it really fully went dead). > > Interesting. Which diagnostics would you have in mind to defer in this way? > > > > > > > Another (maybe only remotely related) aspect of this project might > > > be getting #pragma GCC diagnostic to work reliably with middle-end > > > warnings emitted for inlined code. That it doesn't work is one of > > > the frustrations for users who run into false positives with "late" > > > warnings like -Wstringop-overflow or -Wformat-overflow. > > Thank you Martin for bringing this up! > > > > > A similar issue is they are not carried along from compile-time to > > LTO link time. I'm not even sure how they are attached to anything > > right now ... certainly not in DECL_FUNCTION_SPECIFIC_OPTIMIZATION. > > This is good to know too. > > I know that there is only a week left to submit a proposal, but I am > thinking of a project proposal that can be summarized in one line as > "Improving the diagnostics infrastructure of GCC," which combines the > original proposal about a finer-grained > TREE_NO_WARNING/gimple_no_warning mechanism along with Richard's and > Martin's ideas of preserving diagnostic pragmas after inlining and for > LTO link time, and maybe Richard's idea of being able to defer > diagnostics until we know for sure that the code in question survives > DCE. Would such a proposal be well-defined and tractable enough for > GSoC? If so, would anyone volunteer to be a mentor for this project? I think there are only vague ideas for TREE_NO_WARNING/defering right now and no concrete ones for the issue of sub-function granular #pragma diagnostics (that means also inlining). Improving how LTO handles [late] warnings might be interesting given that could be implemented function-granular (where we already have function-granular optimization options). But I'm not sure my statement quoted from above is even correct -- IIRC #pragma GCC diagnostic does work for late warnings on a function-granular level (does it?), so the LTO issue might be simply mis
Re: GSOC Proposal
On 2019-04-03 7:30 a.m., Richard Biener wrote: > On Mon, 1 Apr 2019, nick wrote: > >> >> >> On 2019-04-01 9:47 a.m., Richard Biener wrote: >>> On Mon, 1 Apr 2019, nick wrote: >>> Well I'm talking about the shared roots of this garbage collector core state data structure or just struct ggc_root_tab. But also this seems that this to be no longer shared globally if I'm not mistaken or this: static vec extra_root_vec; Not sure after reading the code which is a bigger deal through so I wrote my proposal not just asking which is a better issue for not being thread safe. Sorry about that. As for the second question injection seems to not be the issue or outside callers but just internal so phase 3 or step 3 would now be: Find internal callers or users of x where x is one of the above rather than injecting outside callers. Which answers my second question about external callers being a issue still. Let me know which of the two is a better issue: 1. struct ggc_root_tabs being shared 2.static vec extra_root_vec; as a shared heap or vector of root nodes for each type of allocation and I will gladly rewrite my proposal sections for that as needs to be reedited. >>> >>> I don't think working on the garbage collector as a separate >>> GSoC project is useful at this point. Doing locking around >>> allocation seems like a good short-term solution and if that >>> turns out to be a performance issue for the threaded part >>> using per-thread freelists is likely an easy to deploy >>> solution. >>> >>> Richard. >>> >> I agree but we were discussing this: >> Or maybe a project to be more >> explicit about regions of the code that assume that the garbage- >> collector can't run within them?[3] (since the GC is state that would >> be shared by the threads). > > The process of collecting garbage is not the only issue (and that > very issue is easiest mitigated by collecting only at specific > points - which is what we do - and have those be serializing points). > The main issue is the underlying memory allocator (GCC uses memory > that is garbage collected plus regular heap memory). > >> In addition I moved my paper back to our discussion about garbage collector >> state with outside callers.Seems we really need to do something about >> my wording as the idea of my project in a nutshell was to figure >> out how to mark shared state by callers and inject it into the >> garbage collector letting it known that the state was not shared between >> threads or shared. Seems that was on the GSoc page and in our discussions >> the issue >> is marking outside code for shared state. If that's correct then my >> wording of outside callers is incorrect it should have been shared >> state between threads on outside callers to the garbage collector. >> If the state is that in your wording above then great as I understand >> where we are going and will gladly change my wording. > > I'm still not sure what you are shooting at, the above sentences do > not make any sense to me. > >> Also freelists don't work here as the state is shared at the caller's >> end which would need two major issues: >> 1. Locking on nodes of the >> freelists when two threads allocate at the same thing which can be a >> problem if the shared state is shared a lot >> 2. Locking allocation with >> large numbers of callers can starve threads > > First of all allocating memory from the GC pool is not the main > work of GIMPLE passes so simply serializing at allocation time might > work out. Second free lists of course do work. What you'd do is > have a fast path in allocation using a thread-local "free list" > which you can allocate from without taking any lock. Maybe I should > explain "free list" since that term doesn't make too much sense in > a garbage collector world. What I'd do is when a client thread > asks for memory of size N allocate M objects of that size but put > M - 1 on the client thread local "free list" to be allocated lock-free > from for the next M - 1 calls. Note that garbage collected memory > objects are only handed out in fixed chunks (powers of two plus > a few special sizes) so you'd have one "free list" per chunk size > per thread. > > The collection itself (mark & sweep) would be fully serialized still > (and not return to any threads local "free list"). > > ggc_free'd objects _might_ go to the threads "free list"s (yeah, we > _do_ have ggc_free ...). > > As said, I don't see GC or the memory allocator as sth interesting > to work on for parallelization until the basic setup works and it > proves to be a bottleneck. > >> Seems that working on the garbage collector itself isn't the issue but >> the callers as I just figured out as related to your state idea. Let me >> know if that's correct and if the wording change I mentioned is fine >> with you as that's the state it seems that needs to
Re: [GSoC]
Hi Avinash, On Thu, Mar 28 2019, Avinash Tiwary wrote: > Hi, > I am Avinash Tiwary, fourth year engineering graduate from BIT Mesra. I > will like to contribute on "Add new math.h and complex.h functions as > built-ins". Please guide me. we are delighted you found contributing to GCC interesting. Please look again at the "Before you apply" section of our GSoC wiki page at https://gcc.gnu.org/wiki/SummerOfCode#Before_you_apply and make sure you are able to build, install and test GCC and then have it generate dumps and step through some function during compilation. Afterwards, if you still find contributing to GCC appealing, look at a suggested idea, try to identify the portion of GCC source which is involved and email us back to the mailing list, describing which idea you liked best and what your thoughts about it are. Good luck, Martin
Re: GCC GSOC 2019
Hello Shubham, On Fri, Mar 29 2019, Shubham Narlawar wrote: > Hi, here is my proposal for the above idea. Please review and suggest > necessary changes. > > https://docs.google.com/document/d/11MNhuuD7dbwAfSW6ZgFrAys9My1Lw1PuMVcAqeNGr7A/edit?usp=sharing I have had a quick look and the proposal seems very nice. How did you select the attributes you want to implement in csmith? It is for example a little strange that you decided to include "pure" but not "const." If you handle visibility, you might as well consider throwing in externally_visible too, I guess. As a stretch goal, the alias function attribute might be useful to exercise nasty paths in GCC IPA optimizations. I assume Andi Kleen has seen this proposal and if he is fine with it, so am I. Thanks, Martin
Re: Putting an all-zero variable into BSS
Hi Andreas, The large default initializers are all filled with zeros which end up in the rodata section, like this: ... and so on. To reduce the size of the executable, it would make more sense to put this into the BSS section. Note that .bss is writable. There is no read-only bss section. Well, nothing is going to write to it (this is not accessible by user code), so that should not be a problem. Regards Thomas
Re: [GSoC 2019] [extending Csmith for fuzzing OpenMp extensions]
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 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. But apart from that it is nice, thanks for applying, Martin
Re: [GSoC 2019] [extending Csmith for fuzzing OpenMp extensions]
On 4/3/19, Martin Jambor 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. > 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 If you could suggest which constructs do you feel more ambitious?, so I could work on it to modify them. > > But apart from that it is nice, thanks for applying, Thanks, Sameeran Joshi > > Martin >
Re: vector alignment
On 4/3/19 5:13 AM, Richard Biener wrote: On Tue, Apr 2, 2019 at 6:20 PM Martin Sebor wrote: GCC tries to align a vector on its natural boundary, i.e., that given by its size, up to MAX_OBJECT_ALIGNMENT. Vectors that are bigger than that are either silently [mis]aligned on that same maximum boundary (PR 89798), silently truncated (and misaligned), or cause an ICE (PR 89797). Compiling the following: __attribute__ ((vector_size (N))) char v; _Static_assert (sizeof (v) == N, "size"); _Static_assert (__alignof__ (v) == N, "alignment"); with N set to 1LLU << I shows these failures: I < 29 succeeds I < 31 fails alignment I < 32 ICE I >= 32 fails alignment and size Attribute aligned doesn't seem to have any effect on types or variables declared with attribute vector_size. The alignment set by the latter prevails. This happens no matter what scope the vector is defined in (i.e., file or local). I have some questions: 1) Is there some reason to align vectors on the same boundary as their size no matter how big it is? I can't find such a requirement in the ABIs I looked at. Or would it be more appropriate to align the big ones on the preferred boundary for the target? For instance, does it make more sense to align a 64KB vector on a 64KB boundary than on, say, a 64-byte boundary (or some other boundary less than 64K?) I don't think there's a good reason. Instead I think that BIGGEST_ALIGNMENT is what we should go for as upper limit, anything bigger doesn't make sense (unless the user explicitely requests it). Sounds good. Changing the alignment will impact object layout. How do you suggest to deal with it? (Presumably for GCC 10.) Issuing an ABI warning and adding an option to override the new setting come to mind as possible mitigating solutions. 2) If not, is it then appropriate to underalign very large vectors on a boundary less than their size? Yes. Ack. 3) Should the aligned attribute not override the default vector alignment? Yes, but doesn't it already? Not if both are specified on the same declaration, as in: typedef __attribute__ ((aligned (1024), vector_size (256))) int V; I opened PR 89950 for this. Martin
Re: GSoC OMPD
Hi, I know my first email is vague. I wanted to throw it out there since the April 9th deadline is coming up. So far, I've built gcc several times. I downloaded the gcc source code. Also I compiled a program with the -fdump options and looked through the files. I've been using gcc for a few years now for projects.. If you think that OMPD will too much for a first time GCC developer, I'm willing to try for a different project. Thank you, Bryan Carroll On Mon, Apr 1, 2019 at 2:05 PM Bryan Carroll wrote: > > Hi, > > My name is Bryan Carroll and I'm a M.S. student in the Applied > Mathematics and Computer Science program at University of Central > Oklahoma. I'm interested in the OpenMP and GDB debugger project. > > A little bit about myself: I've been programming for about 6 years, > the majority of those years in C++ or C. Last year I started learning > about parallelization. I taught myself MPI and recently started > learning OpenMP. I have some experience with compiling - I'm taking a > Progamming Languages class right now. The final project is an > assembler. > > I know how to debug programs. However, I don't really know much about > how debuggers work. I also don't really know about how OpenMP works > underneath the directives. I very much want to learn about these > topics. I'm very much willing to learn and think I could be of help to > this project. > > What I'd like to know and discuss: What other pre-requisites are there > other than those listed on the GNU GSoC page? Also what would the > goals and timeline look like? > > Thank you for your time, > > Bryan Carroll > M.S. at University of Central Oklahoma
[GSoC] TySan
Hi, I hope you are healthy and all well I was applying to GCC GSoC and I want to implement TySan in GCC I am very fluent with C (although i prefer lisp/scheme , but i used C way much more) I am good at C++ , Python and Java bash scripting and I know fair enough about GCC (using it ,about internals ;actually GCC internals are really the hugest so i would be lying if i said i know all of it, but i know fair enough) just btw i wanted to know if it was okay t read how TySan was implemented in LLVM (would there be any legal problem ?!) Thanks in advance for your time Looking forward to do something great with you My Best Wishes
[ GSoC ] TySan
Hi, I hope you are healthy and all well I was applying to GCC GSoC and I want to implement TySan in GCC I am very fluent with C (although i prefer lisp/scheme , but i used C way much more) I am good at C++ , Python and Java bash scripting and I know fair enough about GCC (using it ,about internals ;actually GCC internals are really the hugest so i would be lying if i said i know all of it, but i know fair enough) just btw i wanted to know if it was okay t read how TySan was implemented in LLVM (would there be any legal problem ?!) Thanks in advance for your time Looking forward to do something great with you My Best Wishes
Re: Putting an all-zero variable into BSS
On Apr 03 2019, Thomas Koenig wrote: > Well, nothing is going to write to it (this is not accessible by > user code), so that should not be a problem. Then don't make it read-only. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: vector alignment
On April 3, 2019 7:59:47 PM GMT+02:00, Martin Sebor wrote: >On 4/3/19 5:13 AM, Richard Biener wrote: >> On Tue, Apr 2, 2019 at 6:20 PM Martin Sebor wrote: >>> >>> GCC tries to align a vector on its natural boundary, i.e., that >>> given by its size, up to MAX_OBJECT_ALIGNMENT. Vectors that are >>> bigger than that are either silently [mis]aligned on that same >>> maximum boundary (PR 89798), silently truncated (and misaligned), >>> or cause an ICE (PR 89797). Compiling the following: >>> >>> __attribute__ ((vector_size (N))) char v; >>> >>> _Static_assert (sizeof (v) == N, "size"); >>> _Static_assert (__alignof__ (v) == N, "alignment"); >>> >>> with N set to 1LLU << I shows these failures: >>> >>> I < 29 succeeds >>> I < 31 fails alignment >>> I < 32 ICE >>> I >= 32 fails alignment and size >>> >>> Attribute aligned doesn't seem to have any effect on types or >>> variables declared with attribute vector_size. The alignment >>> set by the latter prevails. >>> >>> This happens no matter what scope the vector is defined in (i.e., >>> file or local). >>> >>> I have some questions: >>> >>> 1) Is there some reason to align vectors on the same boundary >>> as their size no matter how big it is? I can't find such >>> a requirement in the ABIs I looked at. Or would it be more >>> appropriate to align the big ones on the preferred boundary >>> for the target? For instance, does it make more sense to >>> align a 64KB vector on a 64KB boundary than on, say, >>> a 64-byte boundary (or some other boundary less than 64K?) >> >> I don't think there's a good reason. Instead I think that >> BIGGEST_ALIGNMENT is what we should go for as upper limit, >> anything bigger doesn't make sense (unless the user explicitely >> requests it). > >Sounds good. Changing the alignment will impact object layout. Do we really apply the alignment there? How do other compilers lay out here? >How do you suggest to deal with it? (Presumably for GCC 10.) >Issuing an ABI warning and adding an option to override >the new setting come to mind as possible mitigating solutions. We could reject these vector types in aggregates in favor of arrays. Of course that ship has sailed... >> >>> 2) If not, is it then appropriate to underalign very large >>> vectors on a boundary less than their size? >> >> Yes. > >Ack. > >> >>> 3) Should the aligned attribute not override the default vector >>> alignment? >> >> Yes, but doesn't it already? > >Not if both are specified on the same declaration, as in: > > typedef __attribute__ ((aligned (1024), vector_size (256))) int V; > >I opened PR 89950 for this. > >Martin
