search for: handwavy

...ox arrives and won?t connect to the Internet, which means we often have to arrange to get someone clueful on-site to fix it. 2. The site is in the middle of some major deployment, a small piece of which is our server, so the LAN isn?t ready, but they demand the box be shipped early anyway for some handwavy business reason. "No, we can?t tell you what static IP to use," they say. "Just configure it on-site," they say. Sigh. Since these systems have 2+ Ethernet ports and we really only need one in normal operations, we?ve taken to configuring the second one for DHCP, so that the...

...s and won?t connect to the Internet, which means we often have to arrange to get someone clueful on-site to fix it. > > 2. The site is in the middle of some major deployment, a small piece of which is our server, so the LAN isn?t ready, but they demand the box be shipped early anyway for some handwavy business reason. "No, we can?t tell you what static IP to use," they say. "Just configure it on-site," they say. Sigh. > > Since these systems have 2+ Ethernet ports and we really only need one in normal operations, we?ve taken to configuring the second one for DHCP, so...

...ssed via option. My suggestion on a route forward here is that we should look at the particular API and areas of the backend that you're having an issue with and figure out how to best communicate the data you'd like to the appropriate area. I realize this probably seems a little vague and handwavy, but I don't know what areas you've been having problems with lately. I'll absolutely help with this effort if you need assistance or guidance in any way. Thanks! -eric On Wed, Jul 8, 2015 at 7:31 AM Daniel Sanders <Daniel.Sanders at imgtec.com> wrote: > Hi, > > >...

...t; My suggestion on a route forward here is that we should look at the particular > API and areas of the backend that you're having an issue with and figure out > how to best communicate the data you'd like to the appropriate area. I realize > this probably seems a little vague and handwavy, but I don't know what areas > you've been having problems with lately. I'll absolutely help with this effort if > you need assistance or guidance in any way. The MIPS specific problems are broad and varied. Some of the bigger ones are: * Building clang on a 32-bit Debian and a 6...

...ler->disassembler execution path. Crush all differences. > > 3. JIT. Same basic approach as (1) to replace the current object code emitter with an MC based one. > a. Hand-wavey stuff. I haven't thought much about this bit yet except in broad terms. > b. More hand waving. Lots of handwavy stuff - fast incremental feedback based optimization <blah> > 4. ??? > > 5. Profit. > > -Jim > > On Sep 14, 2010, at 10:02 AM, Jason Kim wrote: > >> Hi everyone, Rafael has graciously given me some pointers for helping >> out on the ARM/MC .s emission infr...

...rward here is that we should look at the > particular > > API and areas of the backend that you're having an issue with and figure > out > > how to best communicate the data you'd like to the appropriate area. I > realize > > this probably seems a little vague and handwavy, but I don't know what > areas > > you've been having problems with lately. I'll absolutely help with this > effort if > > you need assistance or guidance in any way. > > The MIPS specific problems are broad and varied. Some of the bigger ones > are: > * Bu...

Hi, In http://reviews.llvm.org/D10969, Eric asked me to explain the wider context of the TargetTuple object that was replacing Triple on llvmdev so here it is. Before I start, I'm sure I don't know the full extent of GNU triple ambiguity and lack of canonicity. Additional examples are welcome. The Problem As you know, LLVM uses a GNU Triple is as a target description that can be relied

Hi Jason, I've just started actively working on this. Coordinating to get things moving even faster sounds great! Can you elaborate a bit on your ultimate goals and use cases are? That might help us better determine a natural breakdown and separation of tasks. Evan and Chris may have suggestions there, too, as I know they're both very interested in getting this stuff fleshed out and

Hi everyone, Rafael has graciously given me some pointers for helping out on the ARM/MC .s emission infrastructure, and I am volunteering to do so. It looks like as of yesterday, the MC obj emitter for ARM is also incomplete (there does not seem to be a ARMMCCodeEmitter.cpp, for example) So if anyone already has started looking into this, I'd like to pool info so as to not step on toes. Any

...t; My suggestion on a route forward here is that we should look at the particular > API and areas of the backend that you're having an issue with and figure out > how to best communicate the data you'd like to the appropriate area. I realize > this probably seems a little vague and handwavy, but I don't know what areas > you've been having problems with lately. I'll absolutely help with this effort if > you need assistance or guidance in any way. The MIPS specific problems are broad and varied. Some of the bigger ones are: * Building clang on a 32-bit Debian and a 6...

> On Apr 17, 2019, at 5:02 AM, Arsenault, Matthew via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > This won’t happen with volatile load/store This is mostly true today, but AFAICT the LLVM memory model doesn’t actually offer this guarantee. It merely says that LLVM treats volatile like C / C++ treats volatile… which isn’t much of a guarantee because C / C++ volatile doesn’t

...ush all differences. > > > > 3. JIT. Same basic approach as (1) to replace the current object code > emitter with an MC based one. > > a. Hand-wavey stuff. I haven't thought much about this bit yet except in > broad terms. > > b. More hand waving. > > Lots of handwavy stuff - fast incremental feedback based optimization > <blah> > > > 4. ??? > > > > 5. Profit. > > > > -Jim > > > > On Sep 14, 2010, at 10:02 AM, Jason Kim wrote: > > > >> Hi everyone, Rafael has graciously given me some pointers f...