search for: chenmindong

...e selector of a "select" is the output of another forward-reference "select" that hasn't been resolved yet? We still cannot determine its type then. Is it possible? Regards, Mindong From: Eli Friedman [mailto:efriedma at quicinc.com] Sent: Friday, July 17, 2020 3:06 AM To: chenmindong <chenmindong1 at huawei.com>; llvm-dev <llvm-dev at lists.llvm.org> Subject: RE: [llvm-dev] BitcodeReader.cpp bug under LTO The DelayedShuffles code in BitcodeReader::parseConstants is solving a sort of similar issue; you might be able to borrow the same approach. -Eli From: llvm-dev...

...-index-only` option to generate *.thinlto.bc and feed it and bitocde to clang to invoke target-specific optimizations(we use gnu as and ld).Do you have any suggestion about this? Regards, Mindong From: Teresa Johnson [mailto:tejohnson at google.com] Sent: Wednesday, November 27, 2019 11:12 PM To: chenmindong <chenmindong1 at huawei.com> Cc: llvm-dev at lists.llvm.org; Yuchao (Michael) <michael.yuchao at huawei.com> Subject: Re: [llvm-dev] ThinLTO Problem Hi Mindong, On Wed, Nov 27, 2019 at 3:29 AM chenmindong via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org...

Hi, I'm working on enabling thinLTO for our custom backend on LLVM-8 with lld to get code size benefits from dead symbol elimination. The code in LTO::run() of LTO.cpp confuses me that, even though thinLTO is specified, runRegularLTO() will be run first and its return value determines whether runThinLTO() will be executed. My question is if it's clearly known that thinLTO is used, is it

Hi guys, We have found a bug of BitcodeReader.cpp in processing an LTO bitcode file. As LLVM doesn't emit use-list for LTO bitcode files, many forward references will happen when BitcodeReader processes the bitcode file, and LLVM uses placeholders for those forward references and resolve them later. When parseConstants() reads in a CST_CODE_CE_SELECT record, e.g. select