> 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
On Feb 10, 2008, at 11:26 PM, Chris Lattner wrote:>> 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.
On Feb 11, 2008, at 10:26 AM, Dale Johannesen wrote:>>> 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