similar to: [LLVMdev] add pass to O2. use as "clang -O2 .."

Hello guys, Do we have a pass to do unconditional branch folding except the one in Codegen? I checked in the lib/Transforms/Scalar, did not see any promising one. thank you, yuanfang

Hello guys, For single scalar pointer parameter, we have 'byval' to specify the pointee is not changed. But for base+range parameters like: declare void @_gfortran_transfer_integer_write(%struct.__st_parameter_dt*, i8*, i32) (This is the fortran runtime api to 'printf' one integer) The 2nd & 3rd args are used to specify the memory of that integer. I didn't find a

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

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

> On Jul 15, 2020, at 12:28, Chen, Yuanfang <Yuanfang.Chen at sony.com> wrote: > > In codegen with NPM, I've made all codegen passes (IR or MIR pass) to be only driven by `llc`. Both due to the way NPM registering pass (on-demand&dynamic instead of static initialization in Legacy PM), and reduce the confusion about which tool (`llc` or `opt`) to test codegen IR passes. >

Hi all, A question about statically linking a pass to clang instead of dynamically loading it at runtime. I am stumped on this bug for a while. I inserted a pass under lib/Transforms/mypass directory, registered it with INITIALIZE_PASS and defined createMyPass in the pass. Also I added file mypass.h in include/llvm/Transforms/ to expose the accessor functions that expose my passes. Entries are

Hi Matt, which analysis is this? ________________________________________ From: Matt Arsenault <whatmannerofburgeristhis at gmail.com> on behalf of Matt Arsenault <arsenm2 at gmail.com> Sent: Tuesday, July 21, 2020 12:02 PM To: Craig Topper Cc: Chen, Yuanfang; Nicolai Hähnle; llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] [RFC] Introducing classes for the codegen driven by new pass

On Sun, Apr 18, 2010 at 4:36 AM, Eugene Toder <eltoder at gmail.com> wrote: > According to documentation Twines should be used only for temporary > values and not stored, so allocating the in heap sounds wrong. Yes, in general you should never be naming Twine directly, except in the case where you need to make a Twine for an integer. All other uses should be considered poor style, as

On 05/28/15 15:27, Yuanfang Chen wrote: > #define GET_BIT(lll) \ > // blah blah > > #define G(label1,label2) \ > { \ > // decent amount code \ > ... > while (1) { \ > GET_BIT(label2); \ > }; \ > } > > void f() { > if (..)

-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

According to documentation Twines should be used only for temporary values and not stored, so allocating the in heap sounds wrong. I think all you need here is static int varNum; ++varNum; Instruction *sstatusInst = new AllocaInst(StatusTy, Twine("status") + Twine(varNum), entry_inst); Instruction *sreqInst = new AllocaInst(ReqTy, Twine("request") + Twine(varNum),

#define GET_BIT(lll) \ // blah blah #define G(label1,label2) \ { \ // decent amount code \ ... while (1) { \ GET_BIT(label2); \ }; \ } void f() { if (..) G('c', 'd'); while ( .. ) G('a','b'); } After perf sampling, a lot

Hello, We have a user that wants to get the code coverage report for his library without turning on instrumentation for the library clients or change how they are built (only the library is instrumented). It seems like the inline member functions defined in headers are not instrumented in this case because the clients are not instrumented. The library itself does not have a copy of the inline

I need to generate variables like status1, status2, status3, ...... request1, request2, request3, ...... this is my code, other unrelated detail are eliminated. static int varNum; static const char *getVarNum() { ++varNum; std::stringstream ss; ss << varNum; std::string *varname = new std::string(ss.str()); return varname->c_str(); } const char *VarNum = getVarNum(); Twine *x1 = new

Hi all, just a quick question, in llvm::TargetData, uint64_t MemberOffsets[1]; // variable sized array! MemberOffsets has two elements, why it's variable sized ? yuanfang -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100423/6e0d57a5/attachment.html>

Hello folks, I want to compile some fortran code to IR, but llvm-gfortran 4.2-2.9 does compile my fortran code. gfortran 4.2.1 fail with the same error. but gfortran 4.4.6 and ifort compiles fine. Attached is the file causing error. Error message is m_List.F90: In function 'exporttostring_': m_List.F90:925: error: conversion to non-scalar type requested I wonder if there any way I can

Hi Yuanfang, > just a quick question, in llvm::TargetData, > > uint64_t MemberOffsets[1]; // variable sized array! > > MemberOffsets has two elements, why it's variable sized ? when a StructLayout object is allocated (in TargetData::getStructLayout), extra memory is allocated, more than that given by the size of the type. The extra memory is interpreted as being part of the

On Tue, Jun 7, 2011 at 2:33 PM, Yuanfang Chen <tabloid.adroit at gmail.com> wrote: > Hello folks, > I want to compile some fortran code to IR, but llvm-gfortran 4.2-2.9 does > compile my fortran code. gfortran 4.2.1 fail with the same error. but > gfortran 4.4.6 and ifort compiles fine. Attached is the file causing > error. Error message is > m_List.F90: In function

We have a similar option (-split-input-file) in `mlir-opt`: https://github.com/llvm/llvm-project/blob/master/mlir/test/Dialect/Affine/invalid.mlir With a single `RUN:` lit invocation the tool itself will loop over all the split sections in the file. This is convenient to test error cases where the tool would abort at the first error otherwise. I don't think we can easily achieve this with a

Like James, Michael suggested, I would prefer the default behavior be consistent across tools (either always read from stdin or no default at all /give error messages) From: James Henderson <jh7370.2008 at my.bristol.ac.uk> Sent: Wednesday, June 26, 2019 2:31 AM To: Alex Brachet-Mialot <alexbrachetmialot at gmail.com> Cc: Fāng-ruì Sòng <maskray at google.com>; LLVMDev