- User Since
- Mar 27 2015, 11:23 AM (237 w, 3 d)
Mon, Oct 7
The close was due to phabricator problem, reopening.
Thu, Oct 3
Wed, Oct 2
The abort() function raises SIGABRT, for which the default behavior is to trigger a coredump. Do we actually want that behavior?
Mon, Sep 30
Fri, Sep 27
Wed, Sep 25
Some high level comments on your filesystem layout standard:
Tue, Sep 24
(See https://reviews.llvm.org/D67983 for the proposed behavior change.)
Note that the test-case diffs are on top of https://reviews.llvm.org/D67982, which I split out to make the actual change in behavior in this commit clearer.
Mon, Sep 23
Sat, Sep 21
Fri, Sep 20
Sparc change looks good.
Don't know about the MIPS one -- seems like probably something upstream should be creating a Constant instead of a TargetConstant, rather than converting it there?
Tue, Sep 17
Mon, Sep 16
The code is attempting to ensure that you don't use RBP as a global register unless RBP is actually a reserved register (being used as the frame pointer in the function.) That's a reasonable goal, but maybe there's another better way to be doing it.
Sep 13 2019
Aug 28 2019
Aug 27 2019
numbers for cacheline size.
Aug 22 2019
That GCC and Clang differ in handling of Atomics is a really unfortunate, longstanding issue.
Aug 20 2019
Aug 2 2019
Doing a websearch for "xtensa isa", I do see that documentation does seem to exist: https://github.com/eerimoq/hardware-reference/blob/master/esp32/xtensa%20Instruction%20Set%20Architecture%20(ISA)%20Reference%20Manual.pdf.
Aug 1 2019
+1 for doing this. I started looking at fixing this when I modified the printer to print proper labels for numbered basic-blocks (instead of comments), but I didn't do so because of the amount of test churn was off-putting.
With this new pass, I think we should be able to remove the code handling the objectsize and is.constant instrinsics in CodegenPrepare, FastISel, SelectionDAGBuilder.cpp, and IRTranslator. Which sure is a nice cleanup.
I think the pass needs to handle the removal of any remaining llvm.objectsize, as well, so that llvm.is.constant(llvm.objectsize(...)) continues to return true -- even if the object size cannot be determined.
Jul 30 2019
I don't really want to promise any particular version, because nobody is really checking that particular versions of git work -- the way our scripts continue work with old versions is when developers use them and report a problem. The only real requirement here is "whatever the oldest version someone's actually used recently".
Jul 29 2019
Given the reference to the bug, seems fine to me to commit an xfail here since nobody is actively working to fix this right now.
I'm not sure the history behind why these were added as default-on warnings....they don't really seem appropriate as default warnings to me, either.
I fear it is necessary: at least it matches documented behaviour of both the Sun/Oracle Studio compilers and gcc.
Jul 23 2019
Is this really necessary? Users don't typically pass -std= to the driver for linking anyways (what do you even pass if you've compiled both C and C++ code?) so this seems a rather odd way to control behavior.
The code you reference in GCC is only for trampolines, while this function is used to implement builtin_clear_cache. AFAICT GCC is just wrong to implement this as a no-op.
Jul 17 2019
I agree, it should have one, especially once we stop supporting separate checkouts, and hopefully can remove redundant copies in other places.
Jul 12 2019
Jun 13 2019
Actually linker scripts do support metacharacter escaping (although, it seems lld does not support this correctly, yet).
Jun 5 2019
Comment updates SGTM.
I like it. Some minor suggestions for a few extra comments, but other than that LGTM.
Jun 4 2019
May 30 2019
I don't think this was correct (where by "correct", there, I mean "what GCC does", as this patch is intended to match GCC behavior).
I don't really have much to say about this, and the patch is probably fine, but I do note that most of the other accessors on this class also return mutable objects.
May 23 2019
One of the other suggestions was to pass a _type_ as a parameter to byval. IMO that would be the nicest idea (but I don't know if it's infeasibly difficult?)
May 22 2019
Sorry for dropping this, a couple more comments, then I think it's good.
May 9 2019
May 6 2019
May 2 2019
Apr 19 2019
There shouldn't be an empty string ("") in the asm output -- that should be a reference to the "l_yes" label, not the empty string. That seems very weird...
Apr 9 2019
Apr 8 2019
If you change to condition on GLIBC instead of linux, I think this is fine to commit (although it still seems unfortunate to me that we're carrying an abandoned codebase which depends on weird broken stuff like this...)
Looks reasonable to me.
Can you please write a test case for this? There's some existing sparcv9 spill tests in llvm/test/CodeGen/SPARC/64spill.ll.
Apr 6 2019
Apr 5 2019
This commit message is rather bare-bones -- I hope that the ultimate commit message will be updated to contain more than just a reference to the RFC thread.
Apr 4 2019
This patch is not correct -- the crash is not with varargs functions specifically, llvm also crashes for a function declared to explicitly take a float/double. The Win64 calling convention code assigns values to xmm registers, but it should not when sse is disabled.
Apr 3 2019
After looking at this a bit more, I realized that this is still insufficient. There's *many* more target-specific constraints than just x86 "i" which sign extend constant integer arguments -- and we'll need to apply this change to every one of them, in all targets.