search for: riddled

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

...l read operation by the BIOS. ----------- MartinS wrote: > Amazingly the size of the code in isohdpfd decreased by one byte > although it's more informative! I still did not find the spot in the Intel manual which tells me the bytes sizes of instructions and their operands. Yesterday i riddled which bytes after the DIVB instruction are the stack address: f6 36 ee 7b and whether to add or 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...

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 move each warning to W=0. Arnd recently submitted a set doing just that for a bunch of them. https://lore.kernel.org/all/20230811140327.3754597-1-a...

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 enable a lot of W=1 warnings using subdir-ccflags-y in our Makefile. For CI/developer use we a...

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

...nsequence, 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, the assumption that audio sample rate == 8 kHz is riddled throughout the Asterisk code.) - Each outgoing RTP packet (from Asterisk) contains just a single Speex frame. Similarly, each incoming RTP packet (from a client) should contain just a single Speex frame. - Some existing clients (such as "linphone") will need to be modified to use the...

...tion of my brain. In addition, it is not very fun to test this on the actual hardware it is designed to run on (although I did manage to track down a 386 with detachable i387 coprocessor, the owner is not sure it still boots). Someday it would be nice to have an audit of this code; it appears to be riddled with bugs relating to segmentation, for example it assumes LDT segments on overrides, does not use the mm->context semaphore to protect LDT access, and generally looks scarily out of date in both function and appearance. I also have a makeover for the pgtable.h code. Splitting operations that...