search for: _llvm_

...e'll need to be able to switch this on and off per calling convention, since I suspect doing this for every call will be impractically slow, even for a validation run. Does the general idea sound reasonable? Note: the focus here is **not** verifying the register allocator or any other part of _LLVM_, but to verify that e.g. a custom calling convention that says that a call target preserves %r10 actually does preserve %r10. This is the compiler enforcing a contract, just at a very low level. Implementation wise, I have a rough prototype that works by running a MachineFunctionPass before regi...

...15:22 +0100, Steven Newbury wrote: > This patch is still not creating elf32_x86_64 objects. No idea > why. :( It does however, fix elf_x86_64 (-m64) code generation on x32 > hosts which is nice. :) I know why. I had assumed Michael Liao (the original patch author) had submitted all the _LLVM_ x32 support as separate patches, and it was just the tests/Clang/compiler-rt support that was missing. It seems not so. Those specific patches he did submit got commited, but many pieces are missing... I should NEVER make such big assumptions! Looks like I'm going to have to go through the o...

This patch is still not creating elf32_x86_64 objects. No idea why. :( It does however, fix elf_x86_64 (-m64) code generation on x32 hosts which is nice. :) --- ./tools/clang/include/clang/Driver/Options.td.orig 2013-05-16 21:51:51.286129820 +0000 +++ ./tools/clang/include/clang/Driver/Options.td 2013-05-16 21:53:24.875004239 +0000 @@ -841,6 +841,7 @@ HelpText<"Enable hexagon-qdsp6

The SymbolTable is a map of Type* to a map of names to Value*. This means that in order to lookup something by name you first have to know what type it is. For the basic types this is fine because you generally always know which basic type you're after. But, for derived types, this can be quite complicated. It isn't always possible to know the exact type. In XPL, types are just names.

...39;t expect making weird/random calling conventions to be likely to have any new/interesting bugs here. But perhaps the architecture doesn't & can't work that way? > > > > > Note: the focus here is **not** verifying the register allocator or > > any other part of _LLVM_, but to verify that e.g. a custom calling > > convention that says that a call target preserves %r10 actually does > > preserve %r10. This is the compiler enforcing a contract, just at a > > very low level. > > You mean with code generated by another compiler/handwritten, b...

On 3 November 2013 05:44, Sean Silva <chisophugis at gmail.com> wrote: > LLVM doesn't provide a runtime or "VM". You basically do these things the > same way that you do them in C. Yes, this unfortunately requires knowing > your target platform's system libraries and how to link to them and such; > LLVM doesn't paper over this. OK. So to be specific, I am