search for: strawman

...follow is to register the option during pass initialization with all the convenient flags and parameters, but refer to a globally defined option storage that enforces the singleton and provides visibility. As long as pass initialization happens before parseCommandLine, usage should be consistent. Strawman: cl::optval<bool> MyOption; // Just the storage, no initialization. MyPass() { // Only registers an option with the same optval once. Option cl::registerOpt(MyOption, cl::init(false), cl::Hidden, cl::desc("Descriptive string..."), ); } -Andy

...me think again about adding support for tuning to a processor rather than generating processor specific code - hence, mtune. I hope this is rather uncontroversial, but happy to discuss at length if anyone thinks we shouldn't add this functionality to the compiler. That said, I have a bit of a strawman outline for what I think needs to happen in general, and while I don't have any concrete plans to attack this soon I thought I'd post it in case someone else was interested: a) split out (in targets where we care) code generation features from tuning features on a per subtarget basis into...

...e below). We are trying to establish if this is an issue with the GCE backend implementation, or if the above commit should be amended to revert to the old behaviour (set VIRTIO_NET_HDR_F_NEEDS_CSUM if ip_summed==CHECKSUM_PARTIAL, otherwise set flags to 0). Reverting back to the old behaviour (see strawman patch below) fixes the issue we were seeing. While we tested with a 4.9.3 kernel, the code in question has not been changed since. Thanks Rolf Background: On Google cloud, we have a setup with a manager node using a 4.9.3 kernel, two worker nodes (one with a 4.9.3 and the other with a 4.4.41 base...

...e below). We are trying to establish if this is an issue with the GCE backend implementation, or if the above commit should be amended to revert to the old behaviour (set VIRTIO_NET_HDR_F_NEEDS_CSUM if ip_summed==CHECKSUM_PARTIAL, otherwise set flags to 0). Reverting back to the old behaviour (see strawman patch below) fixes the issue we were seeing. While we tested with a 4.9.3 kernel, the code in question has not been changed since. Thanks Rolf Background: On Google cloud, we have a setup with a manager node using a 4.9.3 kernel, two worker nodes (one with a 4.9.3 and the other with a 4.4.41 base...

...;re at an extremely early stage. We too will need a dependence analysis interface that can support fairly aggressive analysis, including strong tests, direction vectors, perhaps distance vectors, and dependence breaking conditions. We were going to start with Wojtek's interface as a strawman. Collaborations on extending the interface or implementation would be very welcome. I'm copying Matthieu Delahaye who is our lead programmer on this effort (he's also on llvmdev). --Vikram Associate Professor, Computer Science University of Illinois at Urbana-Champaign http://llvm.or...

But it is more work: My strawman proposal only needs a very mechanical change of adding one xxx.init(); line for each global. Putting the variables into context classes is more involved: You have to actually decide on the appropriate context class for each of them and you will face lots of small helper functions outside of classes...

...t_globals() {` which definitely can be “static” and it is quite unclear to me how you’re gonna trigger the registration for it. > >> On Dec 13, 2016, at 3:43 PM, Matthias Braun <mbraun at apple.com <mailto:mbraun at apple.com>> wrote: >> >> But it is more work: My strawman proposal only needs a very mechanical change of adding one xxx.init(); line for each global. Putting the variables into context classes is more involved: You have to actually decide on the appropriate context class for each of them and you will face lots of small helper functions outside of classes...

...l for one you’re snippet includes a `static void init_globals() {` which definitely can be “static” and it is quite unclear to me how you’re gonna trigger the registration for it. > On Dec 13, 2016, at 3:43 PM, Matthias Braun <mbraun at apple.com> wrote: > > But it is more work: My strawman proposal only needs a very mechanical change of adding one xxx.init(); line for each global. Putting the variables into context classes is more involved: You have to actually decide on the appropriate context class for each of them and you will face lots of small helper functions outside of classes...

...extremely early stage. We too will need a dependence analysis > interface that can support fairly aggressive analysis, including > strong tests, direction vectors, perhaps distance vectors, and > dependence breaking conditions. We were going to start with Wojtek's > interface as a strawman. Collaborations on extending the interface or > implementation would be very welcome. I'm copying Matthieu Delahaye > who is our lead programmer on this effort (he's also on llvmdev). Is there some code of the interface we can discuss? I'm more than happy to provide input, req...

...tion. I see that there was a previous discussion about how to appropriately remove them. Did anything ever come about? I've attempted running the pass "always" per the original discussion. While that works for me, I doubt it's acceptable for all languages, targets, etc. See my strawman patch. Any recommendations on a smaller hammer fix that would be upstreamable? I like the idea of a cleanup pass, but even that seems too special case. Joe ______________________________ Joe Abbey Senior Director of Product Development Arxan Technologies jabbey at arxan.com<mailto:jabbey at a...

...to register the option during pass initialization with all the convenient flags and parameters, but refer to a globally defined option storage that enforces the singleton and provides visibility. As long as pass initialization happens before parseCommandLine, usage should be consistent. > > Strawman: > > cl::optval<bool> MyOption; // Just the storage, no initialization. > > MyPass() { > // Only registers an option with the same optval once. > Option cl::registerOpt(MyOption, cl::init(false), cl::Hidden, > cl::desc("Descriptive string....

...) The full list of changes that could be made to make F18 more LLVM-like is very long. We're interested in identifying what the absolute dealbreakers are that block inclusion into the monorepo and which changes would be acceptable to make after inclusion to the monorepo. We've come up with strawman lists for each and would like to propose the following plan of action: 1. We have captured our strawman proposal for all the changes that need to happen to F18 to make it ready for inclusion into the monorepo on a github project board: https://github.com/orgs/flang-compiler/projects/8 (also re...

...Maybe we should be able to say something like: something.expects(:foo).with(someArguments).with(otherArguments).otherwise(:stub) something_else.expects(:bar).with(arguments).otherwise(:pass) # if the arguments don''t match pass the method to the real object Which is really just a strawman to see if a discussion ensues. There are other issues like providing return values, and perhaps optionally passing a method through after verification that it was called with the expected arguments. Comments? -- Rick DeNatale My blog on Ruby http://talklikeaduck.denhaven2.com/ -------------- ne...

> We should also think about how to call std::terminate when cleanup dtors throw. The current representation for Itanium is inefficient. As a strawman, I propose making @__clang_call_terminate an intrinsic: … That sounds like a good starting point. > Chandler expressed strong concerns about this design, however, as @llvm.eh.get_capture_block adds an ordering constraint on CodeGen. Once you add this intrinsic, we *have* to do frame layout of...

I don’t believe it is any more work (except the registry infrastructure) to do than you strawman proposal. > On Dec 13, 2016, at 3:36 PM, Matthias Braun <mbraun at apple.com> wrote: > > I don't agree with an ideological "burn and remove all the globals" stance. For one thing that means heavy rewriting (we would need to move all the Statistic variable into classes...

...filled at the lib/Taget/<your target>/MCTargetDesc level. In <your targetMCCODEEmitter.cpp for at least text. Some other source file for data. It would be nice if someone could prove that the support is already there and I don't have to do anything to get it, but if not, is the above strawman reasonable? If so, I'll implement it and put it up for review. Cheers, Jack -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111220/0285840a/attachment.html>

...ablish if this is an > issue with the GCE backend implementation, or if the above commit > should be amended to revert to the old behaviour (set > VIRTIO_NET_HDR_F_NEEDS_CSUM if ip_summed==CHECKSUM_PARTIAL, otherwise > set flags to 0). > > Reverting back to the old behaviour (see strawman patch below) fixes > the issue we were seeing. While we tested with a 4.9.3 kernel, the > code in question has not been changed since. > > Thanks > Rolf > > Background: > On Google cloud, we have a setup with a manager node using a 4.9.3 > kernel, two worker nodes (one...

...the sense should be inverted. > > > Mapping success/error onto a bool will always be ambiguous. Is there some better pattern? Perhaps returning ErrorOr<void> instead of a bool would make it clearer. In practice that would mean a ! in the if statement, which runs counter to your strawman that if every client uses ! that the sense should be flipped, e.g.: if (!parse(xx)) // handle error or that test for error could be made obvious via: if (error_code ec = parse(xx)) // handle error -Nick -------------- next part -------------- An HTML attachment was scr...

...for this?). I wonder if there is a solution for having the ability to call these inline functions in an optimized build? Would modules solve this (with the right debugger support)? The `__attribute__(used)` could be used to produce "release" build with "debug library support" (strawman wording), or better, without source modification: a compiler flag could be used to automatically add the "used" semantic to every inline function (and force emit all the inline function for all class template instantiation, but that may be too costly). I wonder if anyone thought about th...

Hi, I'd like to use R to do what excel pivot tables do, and plot results. I've never used R before, and I've managed to do something, but it's quite a lot of code to do something simple. I can't help but think I'm not "Doing it the R way". I could be using R for the wrong thing, in which case, please tell me off. I was hoping something like plot(by(t,