similar to: Request for comments on optimizing assembler

On 5/30/2017 11:00 AM, Quentin Colombet via llvm-dev wrote: > The way I was seeing this happening is by changing incrementally the > parser of the MIR format. Basically, I’d like the parser to get smarter > and smarter to a point where it could understand assembly mnemonics and > build the MachineFunction. The rest of the infrastructure would stay the > same. I'm not sure

One thing I want to mention. I believe in the current legacy pass manager implementation only one MachineFunction ever exists at a time. It is deleted before the next MachineFunction is created. This is very important for memory usage. I think the MachineOutliner being in the pipeline may create an exception to this. I think the initial version of retpoline used a ModulePass and that had to be

Hi all, I like all the ideas so far. Here are my thoughts: I think that fundamentally users of LLVM should be able to opt-in to more aggressive or intensive computation at compile time if they wish. Users' needs differ, and while a 33% increase in clang LTO is absolutely out of the question for some people, for those developing microcontrollers or HPC applications that may well be

-Yuanfang > -----Original Message----- > From: Arthur Eubanks <aeubanks at google.com> > Sent: Monday, July 13, 2020 12:49 PM > To: Chen, Yuanfang <Yuanfang.Chen at sony.com> > Cc: LLVM Developers' List <llvm-dev at lists.llvm.org> > Subject: Re: [llvm-dev] [RFC] Introducing classes for the codegen driven by > new pass manager > > While we're

(NPM: new pass manager; LPM: legacy pass manager) Hello, community While we're still working towards using NPM for optimizer pipeline by default, we still don't have a machine pass interface and the corresponding machine pass manager using NPM. The potential benefits using NPM aside, this inhibits us from making any progress on deprecating LPM for the codegen pipeline which blocks

Hi, [Apologies to those receiving this mail twice - used the old list address by accident] In LLVM it is currently not possible to write a Module-level pass (a pass that modifies or analyzes multiple MachineFunctions) after DAG formation. This inhibits some optimizations[1] and is something I'd like to see changed. The problem is that in the backend, we emit a function at a time, from DAG

Hi everyone. We're interested in contributing a Hexagon assembler to MC and we're looking for comments on a good way to integrate the grammar in to the infrastructure. We rely on having a robust assembler because we have a large base of developers that write in assembly due to low power requirements for mobile devices. We put in some C-like concepts to make the syntax easier and this

Patch for review. On Mon, Aug 21, 2017 at 11:45 PM Puyan Lotfi <puyan.lotfi.llvm at gmail.com> wrote: > Ping. > > Still working on preparing code for review. Will have a patch for review > ready in the coming days. > > PL > > On Tue, Aug 15, 2017 at 12:06 PM Puyan Lotfi <puyan.lotfi.llvm at gmail.com> > wrote: > >> Hi, >> >> >>

On Wed, Feb 18, 2015 at 6:58 AM, Colin LeMahieu <colinl at codeaurora.org> wrote: > It might help after adding explicit types where needed and before adding > the opaque pointer type, to change all pointers to a single type in the > existing type system, i8* could work or maybe a weird type that would shake > out any issues like i99*. > I'm not sure this would help

Hi Krzysztof Thank you very much for your quick and clear reply. I know that MIR may not match hardware instructions directly. However, I think the semantics should be similar. For example, the first instruction is a store-multiple instruction in ARM. I think the first four MIR I shown should have the similar semantics with the first three hardware instructions. I still cannot see the

Hi, [+ Quentin] Sorry for the late reply. > On Feb 13, 2019, at 9:09 AM, Nikola Prica <nikola.prica at rt-rk.com> wrote: > > On 12.02.2019. 18:06, Adrian Prantl wrote: >> [+ some folks more knowledgable about the Machine layer than me.] >> > That would be useful for us too! :) > > >>> On Feb 12, 2019, at 5:07 AM, Nikola Prica <nikola.prica at

Hi all, As much as possible I would rather we avoid any kind of metadata in MIR to express the semantic of instructions. Instead I would prefer that each back provides a way to interpret what an instruction is doing. What I have in mind is something that would generalize what we do in the peephole optimizer for instance (look for isRegSequenceLike/getRegSequenceInputs and co.) or what we have for

Hi, I noticed that a while ago the isSSA flag was removed from MIR, and this property is now computed. However, the deduction only checks the virtual registers (whether they are assigned to more than once). Now I have MIR tests which live after RA, so they only contain physical registers, so the parser determines they are in SSA form. These tests now fail because some of our passes can be

It sounds like what you’re asking is, rather that universally calling RelocationRef::getOffset inside llvm-objdump.cpp I should: * Check if Obj “isRelocatableObject” * If it is, call RelocationRef::getOffset() * If it isn’t o Call RelocationRef::getAddress() o Build an ordered map of all sections and their bounds, check if the relocation lands within a section o

Hello list. I am hoping for some help with a relatively simple problem. I have a data frame arranged as below. I want to be able to count the occurrence of each gene (eg let-7e) by Experiment. In other words how many times does a given gene crop up in the dataframe. I tried table but couldn't work out how to get the output I want. I have also considered rearranging this data into a list (by

Hi! So far, GlobalISel only supports very basic inline assembler constructs (no input/output operands, only simple memory clobbers). In [0], I'm adding support for generic register, immediate, memory and clobber constraints. The code is more or less a direct port from the handling in SelectionDAGBuilder. Before moving on with target specific constraints, I'd like to discuss the

Through converting a miRNAs file from FASTA to character format I get a vector which looks like the following: > nml [1] "hsa-let-7a MIMAT0000062 Homo sapiens let-7a" [2] "hsa-let-7b MIMAT0000063 Homo sapiens let-7b" [3] "hsa-let-7c MIMAT0000064 Homo sapiens let-7c" [4] "hsa-let-7d MIMAT0000065 Homo sapiens

[+ some folks more knowledgable about the Machine layer than me.] > On Feb 12, 2019, at 5:07 AM, Nikola Prica <nikola.prica at rt-rk.com> wrote: > > Hi, > > I am one of the authors of this feature. On Phabricator, we agreed to > take discussion whether encoding this in IR and threading it through the > compiler or performing a late MIR analysis is the better approach.

Hello list. I have a vector of values: eg > head(diff_mirs_list) [1] "hsa-miR-26b" "hsa-miR-26b" "hsa-miR-23a" "hsa-miR-27b" "hsa-miR-29a" [6] "hsa-miR-29b" and I would like to conditionally replace each value in this vector with a number defined in a dataframe: > fc ???????????? Probe ave.fc 1?????? hsa-let-7a?? 1.28 2?????

On Wed, Jul 15, 2020 at 6:39 PM Chen, Yuanfang via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Indeed, but there is a distinction about their position in the pipeline. We run opt & codegen pipeline separately, Why, though? Is there a reason why this inherently makes sense, or is it just a historical accident? At least to me it seems that it would make more sense to run all passes