search for: riddles

Hi, everyone: R is new to me. I am writing a nested loop to simulate data for t-test. The following code is wrong. The subscript is out of bounds. Could anyone tell me how to revise it? Thanks, Riddle Chin. result<-matrix(ncol=5, nrow=1000) colnames(result)<-c('N=20','N=40','N=60','N=80','N=100') for (i in 1:1000){ for (j in

I'd be interested in using this but I have to wait until someone ports this to firefox (or at least chromium). Thanks for sharing it though! On 3/31/20 2:16 PM, River Riddle via llvm-dev wrote: > For those interested I've uploaded to the chrome store to make installs > easier. An install link is now included on the repo. > > -- River > > On Mon, Mar 30, 2020, 1:44 PM

Hi River, Thanks for the detailed explanation. If people are okay for you to move forward, like I said to Andrey, I won’t oppose. I feel sad we have to split our effort on outlining technology, but I certainly don’t pretend to know what is best! The bottom line is if people are happy with that going in, the conversation on the details can continue in parallel. > On Jul 24, 2017, at 4:56 PM,

Hi Quentin, I understand your points and I believe that some meaning is being lost via email. For performance it's true that that cost isn't necessarily modeled, there is currently only support for using profile data to avoid mitigate that. I was working under the assumption, possibly incorrectly, that at Oz we favor small code over anything else including runtime performance. This is

...to subtract 2 with that address. Finally isohdpfc.bin told me that "ee" must become "f0" to correct the bug. (This would mean we can correct existing ISOs by this bash command echo -n $'\xf0' | dd conv=notrunc bs=1 seek=256 count=1 of=the.iso ) ----------- All old riddles seem solved now. The confusion of the two stack addresses explains the failures. The new riddle is: Why did isohdpfd.bin not load correctly the content of the following 79 blocks of isolinux.bin ? Is this reproducible in multiple attempts ? ----------- Have a nice day :) Thomas

Hi Quentin, I appreciate the feedback. When I reference the cost of Target Hooks it's mainly for maintainability and cost on a target author. We want to keep the intrusion into target information minimized. The heuristics used for the outliner are the same used by any other IR level pass seeking target information, i.e TTI for the most part. I can see where you are coming from with

Hi Jessica, The comparison to the inliner is an interesting one but we think it's important to note the difference in the use of heuristics. The inliner is juggling many different tasks at the same time, execution speed, code size, etc. which can cause the parameters to be very sensitive depending on the benchmark/platform/etc. The outliners heuristics are focused solely on the potential code

Hi Andrey, Questions and feedback are very much welcome. - The explanation as to why the improvements can vary between the IR and MIR outliner mainly boil down to the level of abstraction that each are working at. The MIR level has very accurate heuristics and is effectively the last post ISel target independent code gen pass. The IR outliner on the other hand has more estimation in the cost

> On Jul 25, 2017, at 9:24 AM, Jessica Paquette <jpaquette at apple.com> wrote: > >> The two passes are pretty different in their approaches to congruency finding, so I don't think it helps to group them as though they were interchangeable "outliner technology". The two passes might be totally orthogonal. > > I think that based off how River described his

On Mon, Jul 24, 2017 at 4:14 PM, Quentin Colombet via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi River, > > On Jul 24, 2017, at 2:36 PM, River Riddle <riddleriver at gmail.com> wrote: > > Hi Quentin, > I appreciate the feedback. When I reference the cost of Target Hooks it's > mainly for maintainability and cost on a target author. We want to keep the

On Thu, 24 Aug 2023, Jani Nikula wrote: > On Thu, 24 Aug 2023, Lee Jones <lee at kernel.org> wrote: > > This set is part of a larger effort attempting to clean-up W=1 > > kernel builds, which are currently overwhelmingly riddled with > > niggly little warnings. > > The next question is, how do we keep it W=1 clean going forward? My plan was to fix them all, then

Hi, I implemented a garbage collector for a language I wrote in college using the llvm gc statepoint infrastructure. Information for statepoints: https://llvm.org/docs/Statepoints.html Example usage of parsing the llvm stackmap can be found at: https://github.com/dotnet/llilc/blob/master/lib/GcInfo/GcInfo.cpp https://llvm.org/docs/StackMaps.html#stackmap-format

On Thu, 24 Aug 2023, Lee Jones <lee at kernel.org> wrote: > This set is part of a larger effort attempting to clean-up W=1 > kernel builds, which are currently overwhelmingly riddled with > niggly little warnings. The next question is, how do we keep it W=1 clean going forward? Most people don't use W=1 because it's too noisy, so it's a bit of a catch-22. In i915, we

On Tue, Aug 15, 2017 at 4:14 PM, River Riddle via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hey Graham, > I worked on pretty much this exact thing last year. I did something > similar to what you described, I traversed the CFG and built potentially > profitable regions from any given valid start node. At that point there > were several road blocks that prevented it

Hi all, Recently I've had some extra time on my hands, so I spent part of the weekend coding up a simple chrome extension to monitor the status of code reviews on the LLVM phabricator instance. This extension is inspired by some other review monitoring tools that I've used in the past. It allows for monitoring revisions that a user needs to review, revisions by the user that need to be

Is there an explanation anywhere of what code that uses a stack map looks like? I'm interested in writing a garbage collector, but it's not clear to me how my code should make use of the stack map format to actually locate roots in memory. -------------- next part -------------- An HTML attachment was scrubbed... URL:

I've been scratching my head over this one for too long. I'm hoping someone out there can solve this riddle. I have two vectors of characters, v1 and v2, both of length L, and two matrices of logicals, m1 and m2, both of dimension N*L. The first matrix of logicals corresponds to the first vector of characters, and the second to the second. The matrices are telling me which of the

Hi Chris, > One particular disagreement that I think very much needs to be revisited in this thread was Jessica's proposal of a pipeline of: > 1. IR outline > 2. Inline > 3. MIR outline IMHO, there is no need to restrict a place of the Outliner in the pipeline at the moment. I hope people representing different architectures will try different configurations and the best will be

FYI, the Asterisk software PBX <http://www.asterisk.org/> has now incorporated my recent patches to support dynamic RTP payload types. As a consequence, its SIP implementation now supports Speex, so if you have a Speex-compatible SIP client, you can use it to make calls using Asterisk. Some caveats: - Only narrowband (8 kHz) Speex is currently supported; not wideband. (Unfortunately,

This round attempts to conclude all of the LDT related cleanup with some finally nice looking LDT code, fixes for the UML build, a bugfix for really rather nasty kprobes problems, and the basic framework for an LDT test suite. It is really rather unfortunate that this code is so difficult to test, even with DOSemu and Wine, there are still very nasty corner cases here - anyone want an iret to