search for: codersnotes

On Fri, Aug 16, 2013 at 2:01 PM, reed kotler <rkotler at mips.com> wrote: > the good news is that (thanks to Simon) the clang driver is working so > well for Mips now that we are more or less switching away from using llc > during development for all our various host/target configurations. > > the bad news is that we have make clang all the time and it is really slow > to

Hi Andrew, this sounded a plausible explanation, because the X86 processor does not have an instruction to calculate the power function. So I tried the llvm.sin.f32 intrinsic, as the X86 processor family does have an instruction for that, but I still get the same problem. While you may still be right, there is at least something else going on as well. Thanks for your input, though. Taco.

the good news is that (thanks to Simon) the clang driver is working so well for Mips now that we are more or less switching away from using llc during development for all our various host/target configurations. the bad news is that we have make clang all the time and it is really slow to do that. we used to be able to just make in the lib/target/Mips and then in llc and it was really fast.

The odds of #define _WINNT_H working are incredibly slim :) You can't include the separate headers (winbase.h etc), you have to just include windows.h Windows defines IMAGE_* whether we like it or not, we can't stop it doing it, so the only reasonable solution is to change LLVM to have it's own set of constant names. Nick Kledzik wrote: > In the Windows SDK headers, is the

If it thinks the symbol is in the BSS section, then it should never have tried to use .comm to emit it I think. On x86 it does not try to mix and match, which is why it works. AFAIK comm symbols are regarded as having no section, rather than being bss, so I think it's a bug in whatever code printed that .comm statement. I'll look into this tomorrow. > Eric Christopher