Re: Scheduler:LLVM vs gcc, which is better
On Mon, Mar 10, 2014 at 6:59 PM, lin zuojian wrote: > > Hi, > I read LLVM code for a while,and a question raise:Whose scheduler is > better? > LLVM brings in the DAG,and make it look important just like IR or > MachineInst.But is that necessary?I don't see what kind of problem > it tries to solve. > From the pipeline of the compiler, LLVM can not do sched2.Is that > suck? I clearly can't speak for GCC developers, but as an LLVM developer I have to say, this seems like a (somewhat rudely phrased) question for the LLVM mailing lists where there are people more familiar with the LLVM internals. Happy to reply in more depth there (or here if folks are actually interested).
Re: Scheduler:LLVM vs gcc, which is better
On Mon, Mar 10, 2014 at 7:33 PM, lin zuojian wrote: > Hi, > I just ask for opinions.I think many GCC developers do familiar with > the opponent.If I ask in the LLVM mailing list, I have to worry > about If they are familiar with GCC, too(what's sched2 pass?). I suspect you will have the same problem on both lists. The internal details of the scheduling system are not likely to be widely known honestly. To provide a very brief summary of what is going on in LLVM to the best of my knowledge (although I am not one of the experts on this area): The DAG (or more fully, the SelectionDAG) is not really relevant to scheduling any more[1]. It is just a mechanism used for legalization and combining the target-specific representation prior to producing very low level "MI" or Machine Instructions. That is, it is entirely an instruction selection tool, not a a scheduling tool. The scheduling takes place amongst the machine instructions either before or after register allocation (depending on the target) and with a wide variety of heuristics. My understanding is that it is attempting to solve the same fundamental scheduling problems as GCC's infrastructure (ILP and register pressure). The infrastructure is the bulk of it though, and that is likely entirely specific to the representation and innards of the respective compilers. Given that LLVM's machine level scheduler is significantly younger than GCC's, I would expect it to be less well tuned and have less complete and/or accurate modeling for some targets. -Chandler [1] Historically, we did both instruction selection and scheduling using the DAG, but the scheduling has moved into the MI layer specifically to address register pressure and ILP concerns that were hard/impossible to handle at a higher level. There is some hope that the DAG goes away completely and is replaced with some simpler selection and legalization framework, but that hasn't yet emerged.
Re: [patch][rfc] How to handle static constructors on linux
[Re-sending this to try to got through to the GCC mailing list... Sorry for the duplication to others... My reply is at the bottom] On Mon, Jun 18, 2012 at 11:08 AM, Chandler Carruth wrote: > On Mon, Jun 18, 2012 at 10:49 AM, Rafael Espíndola > wrote: >> >> > The GNU linker has support to merge .ctor's into init_array. Does the >> > gold linker have the same feature? This seems more like the real fix >> > rather than just hacking around the issue. >> >> Recent version have it. I found the bug when using gold 2.21 which >> doesn't. What seems to happen is: >> >> * In an old linux system, the linker leaves ctors in .ctors, >> crtbeginS.o has a call to __do_global_dtors_aux. The net result is >> that _init calls the constructors. >> * In an all new linux system, the compiler uses .init_array (or the >> linker moves it there) and crtbeginS.o has nothing to do with >> constructors. >> * If we have a compiler that doesn't use .init_array and gold 2.21 in >> a new linux system, we hit the bug. >> >> So this is not as bad as I was expecting (old programs still work), >> but it is still a somewhat annoying ABI change to handle. > > > Thanks to Andrew for explaining some of this to Rafael, and thanks to Rafael > for breaking it down and getting it through my thick skull. =] I now > understand what's going on much better. It is indeed not as bad as I was > expecting. > > However, as Rafael says, this is an annoying ABI change to handle. It seems > that the song-and-dance to maintain backwards compatibility has been > achieved, but the cost has been to introduce a pretty nasty dependency on > newer versions of ld / gold in order to cope with '.o' files built by old > compilers (which we are sometimes stuck with). > > In figuring out how best to support this situation, the question I'm left > with, and would love if someone from the GCC community familiar with the > initial change could answer is: why was this change worth the cost we're now > paying? What is the expected upside to putting constructors in .init_array? > > Thanks, > -Chandler
Re: [patch][rfc] How to handle static constructors on linux
On Mon, Jun 18, 2012 at 11:08 AM, Cary Coutant wrote: >> So this is not as bad as I was expecting (old programs still work), >> but it is still a somewhat annoying ABI change to handle. I think we >> can add support for this in clang in 3 ways: >> >> 1) Require new linkers when using gcc 4.7 libraries. >> 2) Ship our own versions of crtbeginS.o (and similars). >> 3) Use .init_array when using gcc 4.7 libraries. >> >> I have most of option 3 implemented. Chandler, do you still think >> that this is a big enough ABI breakage that it should not be >> supported? > > You keep using the terms "ABI change" and "ABI breakage", but I think > you're using those terms a little too freely. The ABI does not specify > the order of initializers across compilation units, so the difference > in behavior -- while perhaps unfriendly -- does not even qualify as an > ABI change, and certainly not as an ABI "breakage". Not at all. The ordering is not the problem from an ABI stance. My concern was with a mixture of object code or dynamic libraries compiled in both the old and the new world. Rafael had indicated that this mixture produced a crashing program. However, he has clarified all of the various layers of compatibility present, and I agree the problem is much less bad than it originally seemed. It seems all that remains is a rather firm version dependency -- a recent linker with support for migrating '.ctors' -> '.init_array' is required to support old object files. > Furthermore, if you're working in chromium, you should be aware that > the new behavior is exactly what the Chrome developers are arguing > for, as it makes the startup faster. It sounds to me like you're > working at cross purposes with the other developers on that project. Ah, perhaps this goes to answer my question from the other mail: why switch to '.init_array'? I agree that reversing the order is essentially orthogonal, and has a straight forward fix, which is largely a convenience to avoid changing behavior needlessly.
Re: [cfe-dev] C++11: new builtin to allow constexpr to be applied to performance-critical functions
On Fri, Oct 19, 2012 at 10:04 PM, Richard Smith wrote:
>
> [Crossposted to both GCC and Clang dev lists]
>
> Hi,
>
> One issue facing library authors wanting to use C++11's constexpr feature is
> that the same implementation must be provided for both the case of function
> invocation substitution and for execution at runtime. Due to the constraints
> on constexpr function definitions, this can force an implementation of a
> library function to be inefficient. To counteract this, I'd like to propose
> the addition of a builtin:
>
> bool __builtin_constexpr_p()
>
> This builtin would only be supported within constexpr function definitions.
> If the containing function is undergoing function invocation substitution, it
> returns true. Otherwise, it returns false. Hence we can implement library
> functions with a pattern like:
>
> constexpr int constexpr_strncmp(const char *p, const char *q, size_t n) {
> return !n ? 0 : *p != *q ? *p - *q : !*p ? 0 : constexpr_strncmp(p+1,
> q+1, n-1);
> }
> __attribute__((always_inline)) constexpr int my_strncmp(const char *p,
> const char *q, size_t n) {
> return __builtin_constexpr_p() ? constexpr_strncmp(p, q, n) : strncmp(p,
> q, n);
> }
>
> Does this seem reasonable?
Yes, especially the primary functionality. However, I have some
concerns about the interface. Let me hypothesize a different
interface:
This stays the same...
> constexpr int constexpr_strncmp(const char *p, const char *q, size_t n) {
> return !n ? 0 : *p != *q ? *p - *q : !*p ? 0 : constexpr_strncmp(p+1, q+1,
> n-1);
> }
But here we do something different on the actual declaration:
>
> [[constexpr_alias(constexpr_strncmp)]]
> int strncmp(const char *p, const char *q, size_t n);
When parsing the *declaration* of this function, we lookup the
function name passed to constexpr_alias. We must find a constexpr
function with an identical signature. Then, at function invocation
substitution of strncmp, we instead substitute the body of
constexpr_strncmp.
This seems more direct (no redirection in the code), and it also
provides a specific advantage of allowing this to be easily added to
an existing declaration in a declaration-only header file without
impacting or changing the name of the runtime executed body or
definition.
-Chandler
PS: Sorry for the dup Clang folks, the GCC list doesn't like my mail client.
