Hi All,
The first draft of the llvm 2.2 release notes are now available:
http://llvm.org/docs/ReleaseNotes.html
The release is scheduled for Monday, so please take a look at them and send me your feedback, or (better yet) just commit fixes directly to the document in llvm/docs/ReleaseNotes.html. In addition to editing improvements I'm particularly interested in adding missing things to the document and getting credit to the right people. Please don't be shy about letting me know if I got something wrong.
The release is an amazing release, LLVM 2.2 rocks!
-Chris
This is a matter of presentation, but some of the "GCC extensions" are standard C99 (now, at least). I noticed long long, C++-style comments and designated initializers.
I have plenty of complaints about the GCC documentation you're pointing at, but this probably isn't the right forum for that. I do think dropping "as fast as macros" from the "inline" description would be a good idea, that's pure propaganda: sometimes it's true and sometimes it isn't.
The miscompilation of code containing both MMX vectors and long double may be worth a mention, but it probably isn't going to bite very many people. (llvm does not insert EMMS everywhere it needs to, or from a different viewpoint, uses MMX when the user didn't tell it to.)
Giving me credit for darwin x86-64 EH is an overstatement, I just made minor mods to existing EH code (Anton's I think).
Looks good overall.
This is a matter of presentation, but some of the "GCC extensions" are
standard C99 (now, at least). I noticed long long, C++-style comments
and designated initializers.
I have plenty of complaints about the GCC documentation you're
pointing at, but this probably isn't the right forum for that. I do
think dropping "as fast as macros" from the "inline" description would
be a good idea, that's pure propaganda: sometimes it's true and
sometimes it isn't.
I completely agree with you here. It looks like the GCC docs were written vs C90 not C99. That whole section of the documentation was more useful when there were a lot of GCC features we didn't support. Now it looks like it can be ripped out and we can just keep a list of things that don't work in our own words. Lets do this for the llvm 2.3 release notes though, after Monday.
The miscompilation of code containing both MMX vectors and long double
may be worth a mention, but it probably isn't going to bite very many
people. (llvm does not insert EMMS everywhere it needs to, or from a
different viewpoint, uses MMX when the user didn't tell it to.)
AFAIK, many commonly used GCC versions don't do this either. If that's the case, I don't think it's worth mentioning, because most people will be concerned with "llvm regressions vs gcc" or something. I believe that if you explicitly use mmx intrinsics you have to insert emms yourself, and that the only other way to get mmx badness is through use of the gcc generic vector extension. If this is true, I think we should be ok.
Giving me credit for darwin x86-64 EH is an overstatement, I just made
minor mods to existing EH code (Anton's I think).
Ok, I'll say 'dale and anton' thanks!
-Chris
This is a matter of presentation, but some of the "GCC extensions" are
standard C99 (now, at least). I noticed long long, C++-style comments
and designated initializers.
I have plenty of complaints about the GCC documentation you're
pointing at, but this probably isn't the right forum for that. I do
think dropping "as fast as macros" from the "inline" description would
be a good idea, that's pure propaganda: sometimes it's true and
sometimes it isn't.
I completely agree with you here. It looks like the GCC docs were
written vs C90 not C99. That whole section of the documentation was
more useful when there were a lot of GCC features we didn't support.
Now it looks like it can be ripped out and we can just keep a list of
things that don't work in our own words. Lets do this for the llvm
2.3 release notes though, after Monday.
ok.
The miscompilation of code containing both MMX vectors and long double
may be worth a mention, but it probably isn't going to bite very many
people. (llvm does not insert EMMS everywhere it needs to, or from a
different viewpoint, uses MMX when the user didn't tell it to.)
AFAIK, many commonly used GCC versions don't do this either. If
that's the case, I don't think it's worth mentioning, because most
people will be concerned with "llvm regressions vs gcc" or something.
I believe that if you explicitly use mmx intrinsics you have to insert
emms yourself, and that the only other way to get mmx badness is
through use of the gcc generic vector extension. If this is true, I
think we should be ok.
I think that is true, but, the situtation with llvm is rather worse than with gcc: llvm uses MMX registers for mem-to-mem copies of 64-bit vectors, while gcc does not. gcc attempts to restrict its use of MMX to the MMX builtins, and the loads and stores connected to them; we think it is possible for RA spilling to use MMX registers erroneously, but this is not common.
I have plenty of complaints about the GCC documentation you're
pointing at, but this probably isn't the right forum for that. I do
think dropping "as fast as macros" from the "inline" description
would
be a good idea, that's pure propaganda: sometimes it's true and
sometimes it isn't.
I completely agree with you here. It looks like the GCC docs were
written vs C90 not C99. That whole section of the documentation was
more useful when there were a lot of GCC features we didn't support.
Now it looks like it can be ripped out and we can just keep a list of
things that don't work in our own words. Lets do this for the llvm
2.3 release notes though, after Monday.
ok.
I ripped this out from mainline ("llvm 2.3") release notes.
The miscompilation of code containing both MMX vectors and long
double
may be worth a mention, but it probably isn't going to bite very many
people. (llvm does not insert EMMS everywhere it needs to, or from a
different viewpoint, uses MMX when the user didn't tell it to.)
AFAIK, many commonly used GCC versions don't do this either. If
that's the case, I don't think it's worth mentioning, because most
people will be concerned with "llvm regressions vs gcc" or something.
I believe that if you explicitly use mmx intrinsics you have to insert
emms yourself, and that the only other way to get mmx badness is
through use of the gcc generic vector extension. If this is true, I
think we should be ok.
I think that is true, but, the situtation with llvm is rather worse
than with gcc: llvm uses MMX registers for mem-to-mem copies of 64-
bit vectors, while gcc does not. gcc attempts to restrict its use of
MMX to the MMX builtins, and the loads and stores connected to them;
we think it is possible for RA spilling to use MMX registers
erroneously, but this is not common.
Ok. I don't think the release notes are a great place to go into this though. Is this an issue we can fix on mainline?
-Chris