similar to: [LLVMdev] Basic block with two return instructions

Fair enough. In that case, is there an elegant way to test whether a basic block already has a terminator instruction? (I can think of several ways to do it in the front-end, but all of them are fairly inelegant. The problem I'm trying to solve is things like 'a return instruction needs to be added to the end of a function, if and only if the programmer didn't already end the function

On Fri, Feb 5, 2010 at 10:56 AM, Russell Wallace <russell.wallace at gmail.com> wrote: > When I generate a simple function with a single basic block with two > return instructions, I had expected that if it did anything at all, it > would use the first one, but it actually seems to ignore the first one > and take the value of the second one. > > I'm guessing what's

Ah! I didn't know about verifyFunction; it does indeed catch it, thanks! I'll leave that call in my code for all cases for the moment, should help identify problems like that. Is there a recommended way to avoid this problem when compiling a language that has an explicit and optional return statement? On Fri, Feb 5, 2010 at 5:25 PM, Garrison Venn <gvenn.cfe.dev at gmail.com> wrote:

Did your test include running llvm::verifyFunction(...) on the function in question? I guess I should test this, but I would have thought this would catch the issue. Garrison On Feb 5, 2010, at 12:13, Russell Wallace wrote: > Fair enough. In that case, is there an elegant way to test whether a > basic block already has a terminator instruction? > > (I can think of several ways to

On Fri, Feb 5, 2010 at 11:30 AM, Russell Wallace <russell.wallace at gmail.com> wrote: > Ah! I didn't know about verifyFunction; it does indeed catch it, > thanks! I'll leave that call in my code for all cases for the moment, > should help identify problems like that. > > Is there a recommended way to avoid this problem when compiling a > language that has an

On Sat, Aug 22, 2015 at 11:57 PM, Michael Zolotukhin <mzolotukhin at apple.com> wrote: > Hi, > > Several passes would have troubles with such code (namely, GVN and > JumpThreading). Can you just choose not to run those particular passes? I suppose the big problem would be if there's a problem with the code generation and related stuff like instruction scheduling and

On Mon, Jan 4, 2010 at 5:41 AM, Kenneth Uildriks <kennethuil at gmail.com>wrote: > On Mon, Jan 4, 2010 at 4:43 AM, Russell Wallace > <russell.wallace at gmail.com> wrote: > > When implementing a language using LLVM as the backend, it is > > necessary to give programs written in that language, access to the C > > standard library functions. The Kaleidoscope

How well does LLVM scale to many basic blocks? Let's say you have a single function consisting of a million basic blocks each with a few tens of instructions (and assuming the whole thing isn't trivially repetitive so the number of simultaneously live variables and whatever is large) and you feed that through the optimisers into the backend code generator, will this work okay, or will it

> On Aug 23, 2015, at 11:35 AM, Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Sun, Aug 23, 2015 at 01:46:12AM +0100, Russell Wallace via llvm-dev wrote: >> On Sat, Aug 22, 2015 at 11:57 PM, Michael Zolotukhin <mzolotukhin at apple.com> >> wrote: >> >>> Hi, >>> >>> Several passes would have troubles

When implementing a language using LLVM as the backend, it is necessary to give programs written in that language, access to the C standard library functions. The Kaleidoscope tutorial shows how to do this for individual functions using extern declarations, but in general it would be necessary to have those predefined for the full standard library. Presumably these would contain exactly the

On Mon, Mar 1, 2010 at 6:00 PM, Dale Johannesen <dalej at apple.com> wrote: > No, C only requires support for objects up to 65535 bytes in size.  C99 5.2.4.1. 65535 bytes would be reasonably sufficient; what's the largest supported by the LLVM code generator?

On Mon, Jan 4, 2010 at 4:43 AM, Russell Wallace <russell.wallace at gmail.com> wrote: > When implementing a language using LLVM as the backend, it is > necessary to give programs written in that language, access to the C > standard library functions. The Kaleidoscope tutorial shows how to do > this for individual functions using extern declarations, but in > general it would

Well yes, LLVM is Turing complete :-) but I take your point, one could in a pinch hack the same functionality in the front-end. Would that likely be easier or harder than doing it properly in the code generator? Other things equal, of course the latter would be preferable. How do LLVM-GCC and Clang handle it? On Mon, Mar 1, 2010 at 3:36 PM, Duncan Sands <baldrick at free.fr> wrote: > Hi

On Mon, Mar 1, 2010 at 7:39 PM, Reid Kleckner <rnk at mit.edu> wrote: > IIRC they lower it themselves, doing whatever the ABI says they > should, which is usually adding a hidden sret parameter to the > function once you get beyond small structs. Okay, so we seem to be saying sret or suchlike is how you pass and return large objects by value in LLVM. What exactly counts as large?

I've finally managed to extract from Kaleidoscope one particular thing that it seems to me should be working and isn't. Given the global declaration extern "C" void foo() {} within the same program I have RTDyldMemoryManager::getSymbolAddressInProcess("foo") And it's returning null. (LLVM 3.8, Windows 7 x64.) What am I missing? -------------- next part

Tried that, still didn't work. Then I tried making a direct API call, GetProcAddress(GetModuleHandle(0),"foo") And this works if and only if __declspec(dllexport) is supplied. So it looks like we were both right. On Sat, Apr 2, 2016 at 9:29 AM, NAKAMURA Takumi <geek4civic at gmail.com> wrote: > Have you tried to add dllexport? > > On Sat, Apr 2, 2016 at 4:23 PM

On 1 July 2015 at 11:34, Russell Wallace <russell.wallace at gmail.com> wrote: > Why do you say spin? You're dismissing all use-cases other than this very narrow one I'd (with my own spin) characterise as "Do What I Mean, I Can't Be Bothered To Get My Code Right". Fair enough, you're arguing in favour of a point; but it's not one I agree with. Tim.

It would appear that the "uniqueid" field is not being populated in the MySQL CDR DB.. Is this an obsolete field or is a bug? Later..

Yes, I'm running all the existing passes that I know how to run. I didn't know they returned change-made. Thanks! On Mon, Dec 21, 2015 at 12:36 PM, Artur Pilipenko < apilipenko at azulsystems.com> wrote: > Are you going to run some of the existing passes? Why can’t you just use > the returned change-made value from the passes? > > Artur > > > On 20 Dec 2015, at

On Sun, Feb 28, 2010 at 9:07 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Sun, Feb 28, 2010 at 1:02 PM, Russell Wallace > <russell.wallace at gmail.com> wrote: >> What's the largest integer such that something like 'return ((a * b) / >> c) >> d' works correctly on all major platforms? > > Twice the size of a pointer, i.e. 64 bits on