search for: 10.1145

Hi, developers, Recently, I read two papers [1], [2] about finding the root causes of compiler bugs. However, I do not find any information in these paper about how compiler developers find the root causes of compiler bugs in practice. So I am curious whether these techniques are useful in practice. For my experience, the outputs of compilers are always used to isolate the causes of compiler

On Thu, Feb 04, 2010 at 13:59:08 -0800, Evan Cheng wrote: > A more pressing need is a pre-regalloc scheduler that can switch modes to > balance reducing latency vs. reducing register pressure. Right. I'm actually working on implementing a variant of IPS (Goodman and Hsu, Code scheduling and register allocation in large basic blocks, http://doi.acm.org/10.1145/55364.55407) based on the

Preallocation Instruction Scheduling with Register Pressure Minimization Using a Combinatorial Optimization Approach G. Shobaki, M. Shawabkeh and N. Abu-Rmaileh ACM Transactions on Architecture and Code Optimization (TACO). vol. 10, issue 3, Article 14 (Sept. 2013) http://dx.doi.org/10.1145/2512432 Regards Ghassan Shobaki, PH.D Assistant Professor Department of Computer Science Princess Sumaya

http://dl.acm.org/citation.cfm?id=2843863 Luke Jones, Ryan Whelan, Jeremy Blackthorne, and Graham Baker. 2015. Flowtables: Program Skeletal Inversion for Defeat of Interprocedural Analysis with Unique Metamorphism. In Proceedings of the 5th Program Protection and Reverse Engineering Workshop (PPREW-5). ACM, New York, NY, USA, , Article 6 , 11 pages. DOI=http://dx.doi.org/10.1145/2843859.2843863

>>>>> "daheiser" == daheiser <daheiser@gvn.net> >>>>> on Tue, 6 Apr 2004 04:24:35 +0200 (CEST) writes: daheiser> It is an error in the algorithm. "it" being the behavior reported in bug report PR#1228 --- [too bad you didn't use the whole string "PR#1228" in your subject; if you had, no new report would have

Dear community, We, a team at IIT Hyderabad are developing an LLVM front end for a networking language called P4 (https://p4.org/). Our work aims to enable LLVM based optimizations for P4. As the P4 language was designed to target many different switch architectures, we feel that P4 can comfortably fit in the LLVM framework where adding targets is more structured. The existing open-source P4

On Feb 5, 2010, at 2:01 AM, Gergö Barany wrote: > On Thu, Feb 04, 2010 at 13:59:08 -0800, Evan Cheng wrote: >> A more pressing need is a pre-regalloc scheduler that can switch modes to >> balance reducing latency vs. reducing register pressure. > > Right. I'm actually working on implementing a variant of IPS (Goodman and > Hsu, Code scheduling and register allocation

In general, finding the root cause in LLVM is not really a big difference than debugging a normal software: Depending on the scenario, if it’s a crash then putting it on a gdb is probably the first step you wanna do. And this usually can tell you the answer pretty fast. More tricky scenarios usually involving developers to leverage various of LLVM-specific diagnosing features, the

>> As part of the advanced compilers course semester project (at >> UIUC), we >> are starting to implement array dependence analysis for LLVM. Great! This is something we've needed for a long time. > I'm currently working on a similar project and hoping to finish it in > about two weeks. Cool! I think the most critical part of this is to get a good

A more pressing need is a pre-regalloc scheduler that can switch modes to balance reducing latency vs. reducing register pressure. The problem is the current approach is the scheduler is locked into one mode or the other. For x86, it generally makes sense to schedule for low register pressure. That is, until you are dealing with a block that are explicitly SSE code in 64-bit mode. In that case,

I was wondering, is there any way to express in the IR that an instruction/instruction sequence/basic block/region/function/module/whatever is an alternate version of another? e.g. let's keep things simple and say that I have an instruction I. An optimization pass reads it and could be able to produce one or more functionally-equivalent instructions I1, ..., In without being really able

## TL;DR We introduce bcov, an open-source binary-level coverage analysis tool [1]. The details are discussed in our paper [2], which is accepted to ESEC/FSE'20. bcov statically instruments x86-64 ELF binaries without compiler support. It features several techniques that allow it to achieve high performance, transparency, and flexibility. For example, running "make

@Ees, Oh, I see what you mean now. Doing such analysis would be useful for a thread block and not just a single thread but as you say you are onto something bigger than just a thread. We had published a short paper in ICS around this which uses polyhedral techniques to do such analysis and reason about uncoalesced access patterns in Cuda programs. You can find paper at

Hi, > Cool! I think the most critical part of this is to get a good > interface for dependence analysis. There are lots of interesting > implementations that have various time/space tradeoffs. > > For example, it would be great if Omega was available as an option, > even if the compiler didn't use it by default. This argues for making > dependence analysis

Many published analyses which build on post-dominance assume a canonical single-dominator-tree form induced by unifying all exits (and often adding a virtual edge from START to END). In contrast, it seems that the current LLVM post-dominator analysis only operates in a mode in which it generates a forest of post-dominator trees, with one rooted at each exit node. The problem this can cause is

Hi LLVM devs, I’d like to describe my problem, and then propose new features of LLVM which would solve it efficiently. I'm building a new statically-compiled programming language, and I plan on using LLVM as the backend. The language will have a runtime with cooperatively managed green threads (user-space "mini-threads", each with their own dynamically allocated stack). A single OS

Torvald Riegel wrote: > On Monday 09 July 2007 19:33, Scott Michel wrote: >> Torvald Riegel wrote: >>> Hi, >>> >>> I'd like to see support for something like this. I have some comments, >>> and I think there is existing work that you can reuse. >> "reuse within the compiler." > > within the LLVM compiler framework, to be

I think you can also avoid the RDF computation using a more directed form of control dependence testing such as described in Keshav Pingali and Gianfranco Bilardi. 1997. Optimal control dependence computation and the Roman chariots problem. ACM Trans. Program. Lang. Syst. 19, 3 (May 1997), 462-491. DOI=http://dx.doi.org/10.1145/256167.256217 However one challenge seems to be fixing the SSA graph

Dear LLVM community, In 2007 Lang Hames developed a Graph Coloring Register Allocator. This allocator was created based on the paper " A generalized algorithm for graph-coloring register allocation" (http://doi.acm.org/10.1145/996841.996875). This algorithm is graph based, and is concerned with register banks that have different register classes and registers that alias. Lang

Paper for LLVM publication list @ http://llvm.org/pubs/ "Generalized Just-In-Time Trace Compilation using a Parallel Task Farm in a Dynamic Binary Translator" Igor Böhm, Tobias J.K. Edler von Koch, Stephen Kyle, Björn Franke, and Nigel Topham ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI), June 2011. DOI-URL: http://dx.doi.org/10.1145/1993498.1993508