similar to: [LLVMdev] Austin user's group

12:00 PM at Bombay Bistro, 183 at Braker next to HEB.

I'm taking Talin's idea and running with it with respect to the Austin area. If you're into LLVM and within easy-enough driving distance to make it worthwhile to get together every month or so in Austin, please post here. If there's enough interest, I'll set something up at a local restaurant or someplace like that.

On Mon, Oct 19, 2009 at 10:40 AM, Kenneth Uildriks <kennethuil at gmail.com> wrote: > I'm taking Talin's idea and running with it with respect to the Austin > area.  If you're into LLVM and within easy-enough driving distance to > make it worthwhile to get together every month or so in Austin, please > post here.  If there's enough interest, I'll set something

I will tentatively schedule it for Friday, 12/4/2009. Unless the group gets significantly larger, we can meet again at Bombay Bistro.

Thursday 11 April Meet you at 6:00pm at Pour House (west of 183). Pour House 11835 Jollyville Rd, Austin, TX 78759 http://pourhousepintsandpies.com/ -- -Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190407/030ce223/attachment.html>

Snow is expected around lunchtime. Let's stay safe and I'll see y'all in January.

On Tue, Oct 6, 2009 at 2:13 PM, Kenneth Uildriks <kennethuil at gmail.com> wrote: > My front-end is sync'd with the trunk now, and working well, but it > required some additional functions exposed in the C bindings.  I > hereby submit them for review and approval for inclusion in the trunk. > LLVMGetAttribute had a bug in it. Here's the revised version of the patch

My front-end is sync'd with the trunk now, and working well, but it required some additional functions exposed in the C bindings. I hereby submit them for review and approval for inclusion in the trunk. -------------- next part -------------- A non-text attachment was scrubbed... Name: cbindings.patch Type: application/octet-stream Size: 7269 bytes Desc: not available URL:

On Sun, Sep 6, 2009 at 3:19 PM, Kenneth Uildriks<kennethuil at gmail.com> wrote: > It would be unfortunate in a way if "this instruction can trap and go > there" is taken to mean "if this instruction has no effect other than > a possible trap, the instruction and the trapping behavior *must* be > preserved". What exactly would the semantics be if the

On Thu, May 27, 2010 at 6:38 PM, Kenneth Uildriks <kennethuil at gmail.com> wrote: > On Thu, May 27, 2010 at 5:47 PM, Evan Shaw <chickencha at gmail.com> wrote: >> I'm writing a frontend with the LLVM C bindings for a language that >> has a goto statement, similar to C's. I'm having some trouble figuring >> out what to do for the case where the label is

On Thu, May 27, 2010 at 8:46 PM, Evan Shaw <chickencha at gmail.com> wrote: > On Thu, May 27, 2010 at 6:38 PM, Kenneth Uildriks <kennethuil at gmail.com> wrote: >> On Thu, May 27, 2010 at 5:47 PM, Evan Shaw <chickencha at gmail.com> wrote: >>> I'm writing a frontend with the LLVM C bindings for a language that >>> has a goto statement, similar to

On Sun, Sep 6, 2009 at 3:53 PM, Kenneth Uildriks<kennethuil at gmail.com> wrote: > On Sun, Sep 6, 2009 at 5:32 PM, Eli Friedman<eli.friedman at gmail.com> wrote: >> On Sun, Sep 6, 2009 at 3:19 PM, Kenneth Uildriks<kennethuil at gmail.com> wrote: >>> It would be unfortunate in a way if "this instruction can trap and go >>> there" is taken to

On Oct 6, 2009, at 5:47 PM, Kenneth Uildriks wrote: > On Tue, Oct 6, 2009 at 2:13 PM, Kenneth Uildriks > <kennethuil at gmail.com> wrote: >> My front-end is sync'd with the trunk now, and working well, but it >> required some additional functions exposed in the C bindings. I >> hereby submit them for review and approval for inclusion in the >> trunk.

On Sun, Sep 6, 2009 at 5:32 PM, Eli Friedman<eli.friedman at gmail.com> wrote: > On Sun, Sep 6, 2009 at 3:19 PM, Kenneth Uildriks<kennethuil at gmail.com> wrote: >> It would be unfortunate in a way if "this instruction can trap and go >> there" is taken to mean "if this instruction has no effect other than >> a possible trap, the instruction and the

On Tue, Nov 10, 2009 at 6:41 PM, Kenneth Uildriks <kennethuil at gmail.com> wrote: > On Tue, Nov 10, 2009 at 6:10 PM, Talin <viridia at gmail.com> wrote: (A similar esoteric use case is: "which of >> the following two types is larger, 3 x int32 or 2 x {}*? -- i.e. the union >> problem.) The size of a union can be compiled into a ConstantExpr. i.e., (sizeof(T1)

On Fri, Aug 28, 2009 at 3:47 PM, Nick Lewycky<nlewycky at google.com> wrote: > > > 2009/8/28 Kenneth Uildriks <kennethuil at gmail.com> >> >> This is by design, of course, (CreateDistinctItem does not return the >> same value given the same caller-visible global state) but I see no >> way to declare a function that: >> >> 1. Returns a

On Tue, Oct 20, 2009 at 12:08 PM, Dan Gohman <gohman at apple.com> wrote: > Unfortunately, yes.  See PR4542.  Progress has been made recently > though -- the optimizers are now ready.  The main things left to do > is to update the documentation and update the testsuite to account > for the change in the meaning of a module without a targetdata string. > > Dan > > So

On Sun, Nov 14, 2010 at 2:37 PM, Kenneth Uildriks <kennethuil at gmail.com> wrote: > On Sun, Nov 14, 2010 at 11:45 AM, Reid Kleckner <reid.kleckner at gmail.com> wrote: >> On Sun, Nov 14, 2010 at 11:17 AM, Kenneth Uildriks <kennethuil at gmail.com> wrote: >>> To fix that and compile C++ correctly while aggressively >>> devirtualizing it, we would need

On Mon, Oct 11, 2010 at 11:10 PM, John McCall <rjmccall at apple.com> wrote: > On Oct 11, 2010, at 2:01 PM, Kenneth Uildriks wrote: >> A better way for a front-end to declare that vtbl-ptr-hacking is not >> expected and not supported is for it to emit llvm.invariant.start and >> llvm.invariant.end calls for it. > > Some of us were talking about this apropos your

On Tue, Oct 12, 2010 at 7:00 AM, Kenneth Uildriks <kennethuil at gmail.com> wrote: > On Mon, Oct 11, 2010 at 11:10 PM, John McCall <rjmccall at apple.com> wrote: >> On Oct 11, 2010, at 2:01 PM, Kenneth Uildriks wrote: >>> A better way for a front-end to declare that vtbl-ptr-hacking is not >>> expected and not supported is for it to emit llvm.invariant.start