- User Since
- Jun 28 2016, 7:50 PM (95 w, 13 h)
Mon, Apr 16
Sat, Apr 7
Mar 8 2018
These changes look great, but I'd suggest explicitly mentioning that SNaN behavior somewhere, the relation of the instructions to the intrinsics etc. Perhaps a section before Fast Math Flags?
Feb 5 2018
Here's a different way to interpret the current situation: instead of seeing the current behavior as "inconsistent", you could see it as "duplication only making sense in some cases". Realistically though, I agree that the code base is probably inconsistent as it is written by lots of people with different practices.
Personally, I don't see the harm in duplicating the comments, and they are useful when you're not using doxygen or some other tool. You're talking about the overriden method situation, but another common one is when you define a class in an anonymous namespace and then implement it later in the same file. The implementation should certainly have a doc comment on it, and if it helps to understand the overview of what the struct is doing, then it makes sense to document it in the class definition as well.
Jan 31 2018
This change LGTM.
Nov 3 2017
Oct 24 2017
Aug 30 2017
LGTM! Thanks @asb
Aug 29 2017
FWIW, I agree with @majnemer's comments here: use of auto in those places doesn't aid in understanding/maintainability of the code, and it is important to mention that the manual loop with an explicitly evaluated end can make sense if the sequence is being mutated in the loop (but also we should recommend a comment to make that explicit!)
Jul 11 2017
Jul 6 2017
Jun 26 2017
I agree we should remove it from the main page. DragonEgg should also be removed.
Jun 25 2017
May 21 2017
May 20 2017
For the record, I remain unconvinced that LLVM's IR should support non-constant vector widths
Nov 5 2016
Oct 28 2016
Thanks for improving this to allow programatic complexity! This looks overall great to me, but again, I'm not the best technical reviewer for X86 backend anymore.
Oct 25 2016
I think there are two things going on here. I think that eli is right: LLVM IR global variables should always be assumable that they don't alias. This is guaranteed by C and other source languages and is important for LLVM to be able to represent. Separately though, I think it makes sense for LLVM globals to have !range metadata to specify that (though disjoint) they live in a specific address range that can fit into immediates.
This seems like a huge improvement over the status quo. Unfortunately, it's been a couple of years since I've worked on this area though, so I'd like you to get someone working on the X86 backend to look at it.
Oct 24 2016
This doesn't seem like the right approach. It would be better to introduce a new top level IR concept to represent this, instead of violating the model of GlobalValue.
Oct 11 2016
Ah, I didn't see it. I'll respond there.
As I mentioned on llvmdev, this approach doesn't make sense to me.
Sep 26 2016
Looks reasonable, please add the standard LLVM file header blob per the coding standards.
I can't provide a technical review for this, but thank you for working on it!
This revision LGTM, making the "const char*" ctor explicit can & should be done as a second step, thanks!
You should be able to make string literals work if you use a template that takes an array of char with the size as a template parameter.
The 0 is for the length, not the actual pointer.
LGTM, might as well use nullptr instead of 0 though.
Sep 13 2016
Sep 12 2016
Aug 30 2016
Aug 18 2016
Aug 17 2016
Aug 16 2016
I think this approach (adding "Commenting out large blocks of code is discouraged, ...") is great!
Aug 15 2016
Overall, looks great. I added some specific detailed comments above. Once you addressed those, I think this is good to merge, thank you for driving this forward Renato!
Aug 11 2016
I'm +1 for this change. While this is a good suggestion for local development of code when you're working on it, we don't want large blocks of code to be checked into the source tree. This document doesn't need legislate how you do your local development :-)
Aug 5 2016
Jul 28 2016
Jul 25 2016
I think it absolutely makes sense to encode the policy for this into the developer policy document, but think we should converge on the mailing list before discussing specific wording for it.
Jul 18 2016
Please send this to llvm-dev for discussion when it converges, thanks!
Jul 13 2016
Jun 28 2016