arm-related links in need of updates
I noticed there's a couple of links on arm.com that changed recently (probably in the last month or so). Can you please help and get those updated? (Even those that redirect.) On http://gcc.gnu.org/gcc-10/changes.html https://developer.arm.com/docs/101028/0009/data-processing-intrinsics https://developer.arm.com/docs/101028/0010/custom-datapath-extension On http://gcc.gnu.org/readings.html http://infocenter.arm.com/help/index.jsp http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.subset.swdev.abi/ In gcc/gcc/doc/extend.texi http://infocenter.arm.com/help/topic/com.arm.doc.ihi0053c/IHI0053C_acle_2_0.pdf http://infocenter.arm.com/help/topic/com.arm.doc.ihi0073a/IHI0073A_arm_neon_intrinsics_ref.pdf In gcc/gcc/invoke.texi http://infocenter.arm.com/help/topic/com.arm.doc.ecm0359818/ECM0359818_armv8m_security_extensions_reqs_on_dev_tools_1_0.pdf Thank you, Gerald
[RFC] LTO Dead Field Elimination and LTO Field Reordering
Hello again, Thanks for replying to my previous thread. I am thankful for all input received and addressed the comments which I could address. I have been working on the past two weeks on fixing the style and adding comments explaining classes and families of functions. I have also added a prototype for field reordering which takes advantage of the infrastructure developed during dead field elimination. I'll explain again what I've been working on and add some technical notes which might be of interest as well for the sake of keeping the discussion to a single post in the mailing list. This patchset adds LTO Dead Field Elimination and Field Reordering as two different passes. I've been testing LTO Dead Field Elimination for some time, compiling all C benchmarks in the SPEC CPU 2017 benchmarking suite. I have not yet tested LTO Field Reordering as extensively but I can say that it compiles all C benchmarks in SPEC CPU 2017 with the exception of gcc. Please note that when combining both transformations, all C benchmarks compile and verify. Please note that the code is made to crash whenever unexpected tree codes are encountered (such as some found in C++ and possibly fortran and ada). One thing that might stand out in this code's review: I implemented my own tree walking mechanism instead of using walk_tree. The reason for this is because walk_tree does not provide a way to set a post-order callback. walk_tree only provides a way to set a pre-order call back. Doing everything in a pre-order traversal would have required complicated keeping track of ancestors and jumping back and forth between ancestors and descendant nodes. Field reordering brings back the intention of -fpack-struct but without violating natural alignment. The field reordering transformation allows to reduce the memory footprint of structs, which not only improves performance, but also memory consumption. So this is an interesting feature on embedded systems with tight memory constraints. Having said that, I welcome all criticisms and will try to address those criticisms which I can. The code is in: refs/vendors/ARM/heads/arm-struct-reorg-wip Few notes: * It is not a "true" ipa pass yes. That is, we can only succeed with -flto-partition=none. * Currently it is not safe to use -fipa-sra. * Brace constructors not supported now. We handle this gracefully. * Only C as of now. * Tests will fail unless finding instructions where addresses of fields is commented out. (Maybe I should create a flag to help testing?). This is because I use pointer arithmetic to compute at runtime the size of the struct that I expect to be transformed. (And sometimes when I don't expect them to be transformed.) * Results of sizeof() and offsetof() are generated in the compiler frontend and thus can’t be changed later at link time. There are a couple of ideas to resolve this, but that’s currently unimplemented. * At this point we’d like to thank the again GCC community for their patient help so far on the mailing list and in other channels. And we ask for your support in terms of feedback, comments and testing.
Re: Coding style for C++ constructs going forward
On 8/7/20 10:06 AM, Luis Machado via Gcc wrote: Hi, cc-ing the GCC mailing list, as we may want to use the same coding style for GDB and GCC. Yesterday I brought this topic up on IRC. I notice we started using more and more the "auto" keyword. In some cases, this is actually useful and makes the code a bit more compact. GDB has been using those more often, whereas GCC, for example, isn't using those too much. Looking at the coding standards for GCC (https://gcc.gnu.org/codingconventions.html), I don't see anything dictating best practices for "auto" use. I guess it is a consensus that "auto" is a good fit when dealing with iterators, lambda's and gnarly templates (but only when the type is already obvious from its use). There are other situations where "auto" may make things a little more cryptic when one wants to figure out the types of the variables. One example of this is when you have a longer function, and you use "auto" in a variable that lives throughout the scope of the function. This means you'll need to go back to its declaration and try to figure out what type this particular variable has. Pedro has pointed out LLVM's coding standards for "auto", which we may or may not want to follow/adopt: https://llvm.org/docs/CodingStandards.html#use-auto-type-deduction-to-make-code-more-readable It sounds like a reasonable idea to me. Thoughts? I agree, it's the way I use auto. I particularly like the auto *foo = expr; idiom, when you're getting a pointer, but the type of the pointee is clear. It informs how you use 'foo'. Are there other C++ constructs people think would benefit from a more formal style guideline? As we move to newer C++ standards over time, it is more likely we will start using newer constructs, and some of those may make the code potentially less readable. -- Nathan Sidwell
Re: Coding style for C++ constructs going forward
On Tue, 11 Aug 2020 at 14:56, Nathan Sidwell wrote: > > On 8/7/20 10:06 AM, Luis Machado via Gcc wrote: > > Hi, > > > > cc-ing the GCC mailing list, as we may want to use the same coding style > > for GDB and GCC. > > > > Yesterday I brought this topic up on IRC. I notice we started using more > > and more the "auto" keyword. In some cases, this is actually useful and > > makes the code a bit more compact. GDB has been using those more often, > > whereas GCC, for example, isn't using those too much. > > > > Looking at the coding standards for GCC > > (https://gcc.gnu.org/codingconventions.html), I don't see anything > > dictating best practices for "auto" use. > > > > I guess it is a consensus that "auto" is a good fit when dealing with > > iterators, lambda's and gnarly templates (but only when the type is > > already obvious from its use). > > > > There are other situations where "auto" may make things a little more > > cryptic when one wants to figure out the types of the variables. One > > example of this is when you have a longer function, and you use "auto" > > in a variable that lives throughout the scope of the function. This > > means you'll need to go back to its declaration and try to figure out > > what type this particular variable has. > > > > Pedro has pointed out LLVM's coding standards for "auto", which we may > > or may not want to follow/adopt: > > https://llvm.org/docs/CodingStandards.html#use-auto-type-deduction-to-make-code-more-readable > > > > > > It sounds like a reasonable idea to me. Thoughts? > > I agree, it's the way I use auto. I particularly like the > auto *foo = expr; > idiom, when you're getting a pointer, but the type of the pointee is > clear. It informs how you use 'foo'. Yes, great suggestion. I use that in libstdc++ too, e.g. include/bits/shared_ptr.h: if (auto* __p = dynamic_cast(__r.get()))
Silly question about pass numbers
For these two dump files: exe.ltrans0.ltrans.074i.cp and exe.ltrans0.ltrans.087i.structure-reorg doesn't the ".074i." mean that this dump was created before the ".087i." dump? If so then why does the ".074i." show GIMPLE that was created in the structure-reorg pass? Thanks, Gary CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and contains information that is confidential and proprietary to Ampere Computing or its subsidiaries. It is to be used solely for the purpose of furthering the parties' business relationship. Any review, copying, or distribution of this email (or any attachments thereto) is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.
Have a look
Hi, Would you like to check out the contacts of *SharpSpring *users? If you are interested please drop me a note so that we can connect and discuss about the opportunity. Thanks in advance! Regards, *Gregorio Gilbert *|Manager Demand Generation| If you do not wish further mail please reply with “Leave Out” in subject line
Why am I seeing free.2 instead of free in exe.ltrans0.ltrans.s??
Note, I'm getting close to getting my part of the structure reorganization optimization minimally functional (my question about value range propagation remains open since I re-enabled a couple of optimizations to bypass it.) Therefore this is actually important for me to resolve. I obviously generated calls to the standard library function "free." Also, similar calls to malloc didn't have that ".2" appended on them. I'd normally handle a problem like this with a Google search but "free.2" gets turned into "free to" and I get an insane number of junk search results. This is obviously an easy question to answer for those that have seen something similar in the past. Thanks, Gary Oblock CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and contains information that is confidential and proprietary to Ampere Computing or its subsidiaries. It is to be used solely for the purpose of furthering the parties' business relationship. Any review, copying, or distribution of this email (or any attachments thereto) is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.
Problem with 64-bit only compiler build
This is a kind of esoteric problem, but all the more annoying for that. As usual I've built my own version of GCC, and then I check it into Git so that all builds can use this one canonical compiler regardless of operating system, etc. After being checked into Git, the compiler started failing to link with an error that it could not find libgcc_s.so, even though it exists in exactly the same place (relatively) as it was before. After some debugging and strace-ing, I discovered that in the failure mode the front-end didn't provide this flag to collect2, which is where libgcc_s.so lives: -L/.../cc/unknown/bin/../lib/gcc/x86_64-unknown-linux-gnu/10.2.0/../../../../x86_64-unknown-linux-gnu/lib/../lib64/. The problem is this: when I built this compiler I only built the 64bit version of it, not the 32bit version. As a result, the lib/. directories are empty: only the lib64 directories have any content. When I check this into Git, of course all empty directories are ignored. So while the /.../cc/unknown/x86_64-unknown-linux-gnu/lib64 directory, where 64bit libgcc_s.so lives, does exist, the /.../cc/unknown/x86_64-unknown-linux-gnu/lib directory doesn't exist, which means the above path cannot be resolved. Of course, I can force the lib directory to exist by adding a dummy file there and I will do so. However, it seems to me that it would be better if GCC would apply a simplifying function to pathnames to reduce all the "/.." elements, before it starts looking for directories, to avoid failing if some unnecessary element doesn't exist. This shouldn't be too difficult since the path will be either the same length as, or shorter than, the original so there's no need to reallocate memory etc.: it can be updated in place. Oddly, I looked through the gnulib library and didn't find any appropriate module for this. It seems like there should be one. Anyway, not sure what people think and whether this is worth an enhancement request in bugzilla.
Re: Coding style for C++ constructs going forward
在 2020/8/11 下午9:55, Nathan Sidwell 写道: > > I agree, it's the way I use auto. I particularly like the > auto *foo = expr; > idiom, when you're getting a pointer, but the type of the pointee is clear. > It informs how you use 'foo'. > > Personally I dislike this syntax. Pointers are objects, and `auto foo = expr;` should suffice. What if the type of `expr` is `unique_ptr` or `optional`? The ptr-operator just can't exist there. So why the differentiation? `auto& foo = ...` and `const auto& foo = ...` are necessary to indicate that the entity being declared is a reference (and is not an object), while `auto*` doesn't make much sense, as I discourage plain pointers in my projects. -- Best regards, LH_Mouse signature.asc Description: OpenPGP digital signature
