Displaying 13 results from an estimated 13 matches for "parseconst".
Did you mean:
parseconf
2020 Jul 16
2
BitcodeReader.cpp bug under LTO
...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 <selty><cond>, <ty><val1>, <ty><val2>
If "ty" here is a vector type and "cond" is a forward reference, LLVM uses i1 as the placeholder type of "cond" if it cannot find "c...
2020 Jul 20
2
BitcodeReader.cpp bug under LTO
...gards,
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 <llvm-dev-bounces at lists.llvm.org<mailto:llvm-dev-bounces at lists.llvm.org>> On Behalf Of chenmindong via llvm-dev
Sent: Thursday, July 16, 2020 7:54 AM
To: llvm-dev at lists....
2013 Aug 25
1
[LLVMdev] Puzzles on DenseMap
...lt;Value*, StringRef, 4> OpResult;
Value *VP = GEP->getPointerOperand();
OpResult[VP] = parseVariable(VP);
for(User::op_iterator sId = GEP->idx_begin(), eId = GEP->idx_end(); sId
!= eId; ++sId) {
Value *VI = *sId;
if(dyn_cast<ConstantInt>(*sId)) OpResult[VI] = parseConstant(VI);
else OpResult[VI] = parseVariable(VI);
}
....
===============================
When I visit OpResult like this:
=====================
std::string result = OpResult[VP];
=====================
And this statement changes the other data in DenseMap. Why?
2013 Jul 29
2
[LLVMdev] opt -O3 causes Assertion `New->getType() == getType() && "replaceAllUses of value with new value of different type!"' failed
...6 0x000000332fa296e6 __assert_fail + 246
7 llc 0x00000000014702df
llvm::Value::replaceAllUsesWith(llvm::Value*) + 173
8 llc 0x00000000006b91e3
llvm::BitcodeReaderValueList::ResolveConstantForwardRefs() + 1127
9 llc 0x00000000006b9d97
llvm::BitcodeReader::ParseConstants() + 339
10 llc 0x00000000006bc634
llvm::BitcodeReader::ParseFunctionBody(llvm::Function*) + 594
11 llc 0x00000000006c2d63
llvm::BitcodeReader::Materialize(llvm::GlobalValue*, std::string*) +
411
12 llc 0x00000000006c290d
llvm::BitcodeReader::MaterializeModule...
2012 Nov 16
0
[LLVMdev] [llvm-commits] [PATCH] fast-math patches!
...(Record[OpNum] & (1 << bitc::FMF_NO_INFS));
2049 FMF.NoSignedZeros = 0 != (Record[OpNum] & (1 << bitc::FMF_NO_SIGNED_ZEROS));
2050 FMF.AllowReciprocal = 0 != (Record[OpNum] & (1 << bitc::FMF_ALLOW_RECIPROCAL));
I found some more in BitcodeReader::ParseConstants(), which I'll scrub after this commits.
Will there be a // fmul N 1, x ==> x? perhaps a // fadd N S 0, x ==> x? as well as other arithmetic identities?
Cheers,
Joe
On Nov 15, 2012, at 9:54 PM, Michael Ilseman <milseman at apple.com> wrote:
> Another round of improved...
2013 Aug 02
2
[LLVMdev] opt -O3 causes Assertion `New->getType() == getType() && "replaceAllUses of value with new value of different type!"' failed
...; 7 llc 0x00000000014702df
>> llvm::Value::replaceAllUsesWith(llvm::Value*) + 173
>> 8 llc 0x00000000006b91e3
>> llvm::BitcodeReaderValueList::ResolveConstantForwardRefs() + 1127
>> 9 llc 0x00000000006b9d97
>> llvm::BitcodeReader::ParseConstants() + 339
>> 10 llc 0x00000000006bc634
>> llvm::BitcodeReader::ParseFunctionBody(llvm::Function*) + 594
>> 11 llc 0x00000000006c2d63
>> llvm::BitcodeReader::Materialize(llvm::GlobalValue*, std::string*) +
>> 411
>> 12 llc 0x0...
2013 Aug 02
0
[LLVMdev] opt -O3 causes Assertion `New->getType() == getType() && "replaceAllUses of value with new value of different type!"' failed
...ssert_fail + 246
> 7 llc 0x00000000014702df
> llvm::Value::replaceAllUsesWith(llvm::Value*) + 173
> 8 llc 0x00000000006b91e3
> llvm::BitcodeReaderValueList::ResolveConstantForwardRefs() + 1127
> 9 llc 0x00000000006b9d97
> llvm::BitcodeReader::ParseConstants() + 339
> 10 llc 0x00000000006bc634
> llvm::BitcodeReader::ParseFunctionBody(llvm::Function*) + 594
> 11 llc 0x00000000006c2d63
> llvm::BitcodeReader::Materialize(llvm::GlobalValue*, std::string*) +
> 411
> 12 llc 0x00000000006c290d
> llv...
2013 Aug 09
0
[LLVMdev] opt -O3 causes Assertion `New->getType() == getType() && "replaceAllUses of value with new value of different type!"' failed
...0x00000000014702df
>>> llvm::Value::replaceAllUsesWith(llvm::Value*) + 173
>>> 8 llc 0x00000000006b91e3
>>> llvm::BitcodeReaderValueList::ResolveConstantForwardRefs() + 1127
>>> 9 llc 0x00000000006b9d97
>>> llvm::BitcodeReader::ParseConstants() + 339
>>> 10 llc 0x00000000006bc634
>>> llvm::BitcodeReader::ParseFunctionBody(llvm::Function*) + 594
>>> 11 llc 0x00000000006c2d63
>>> llvm::BitcodeReader::Materialize(llvm::GlobalValue*, std::string*) +
>>> 411
>>>...
2008 Oct 03
0
[LLVMdev] memory leaks in *Type::get() and Constant*::get()
...: llvm::ConstantInt::get(llvm::APInt const&)
(Constants.cpp:272)
by 0x860E831: llvm::ConstantInt::get(llvm::Type const*, unsigned long
long, bool) (Constants.cpp:254)
by 0x860ECE2: llvm::Constant::getNullValue(llvm::Type const*)
(Constants.cpp:109)
by 0x85E7AB0: llvm::BitcodeReader::ParseConstants()
(BitcodeReader.cpp:768)
by 0x85EDE17: llvm::BitcodeReader::ParseModule(std::string const&)
(BitcodeReader.cpp:1090)
by 0x85EF35F: llvm::BitcodeReader::ParseBitcode()
(BitcodeReader.cpp:1367)
by 0x85EF40B: llvm::getBitcodeModuleProvider(llvm::MemoryBuffer*,
std::string*) (Bitc...
2012 Nov 16
2
[LLVMdev] [llvm-commits] [PATCH] fast-math patches!
Another round of improved patches, and a patch for documentation changes to LangRef.
* Make comments more up to date
* Use 'arcp' instead of 'ar'
* Use logical ||
Still based off of r168110
On Nov 15, 2012, at 3:31 PM, Michael Ilseman <milseman at apple.com> wrote:
>
> On Nov 15, 2012, at 3:23 PM, Joe Abbey <joe.abbey at gmail.com> wrote:
>
2011 Jul 27
0
[LLVMdev] Linking opaque types
...mp;& "Element number out of range!"),
function getElementType, file
/Users/talin/Projects/llvm/include/llvm/DerivedTypes.h, line 268.
5 0x0000000100158f27 in llvm::StructType::getElementType (this=0x10180f310,
N=0) at DerivedTypes.h:268
#6 0x00000001001b8b54 in llvm::BitcodeReader::ParseConstants
(this=0x101813800) at
/Users/talin/Projects/llvm/lib/Bitcode/Reader/BitcodeReader.cpp:1256
#7 0x00000001001be481 in llvm::BitcodeReader::ParseModule
(this=0x101813800) at
/Users/talin/Projects/llvm/lib/Bitcode/Reader/BitcodeReader.cpp:1578
#8 0x00000001001bf8fb in llvm::BitcodeReader::ParseBi...
2011 Jul 27
2
[LLVMdev] Linking opaque types
On Jul 26, 2011, at 8:11 AM, Talin wrote:
>>
>> If that's true, then it means that we're back to the case where every type has to be fully defined down to the leaf level.
>
> I'm not sure what you mean. LLVM is perfectly fine with opaque structs so long as you don't "deference" them, GEP into them, need their size, etc.
>
> Let me try with
2017 Apr 04
3
RFC: Adding a string table to the bitcode format
On Tue, Apr 4, 2017 at 12:36 PM, Duncan P. N. Exon Smith <
dexonsmith at apple.com> wrote:
>
> On 2017-Apr-04, at 12:12, Peter Collingbourne <peter at pcc.me.uk> wrote:
>
> On Mon, Apr 3, 2017 at 8:13 PM, Mehdi Amini <mehdi.amini at apple.com> wrote:
>
>>
>> On Apr 3, 2017, at 7:08 PM, Peter Collingbourne <peter at pcc.me.uk> wrote:
>>