On Tue, May 7, 2019 at 7:40 PM Richard Trieu wrote:
>
>
> From: David Blaikie
> Date: Mon, May 6, 2019 at 4:39 PM
> To: Richard Trieu
> Cc: cfe-commits
>
>> On Mon, May 6, 2019 at 4:24 PM Richard Trieu wrote:
>> >
>> > There was no cycle for this crash.
>>
>> Oh, yeah, didn't mean to imply there
*From: *David Blaikie
*Date: *Mon, May 6, 2019 at 4:39 PM
*To: *Richard Trieu
*Cc: *cfe-commits
On Mon, May 6, 2019 at 4:24 PM Richard Trieu wrote:
> >
> > There was no cycle for this crash.
>
> Oh, yeah, didn't mean to imply there were - but that a system designed
> to prevent cycles might also
On Mon, May 6, 2019 at 4:24 PM Richard Trieu wrote:
>
> There was no cycle for this crash.
Oh, yeah, didn't mean to imply there were - but that a system designed
to prevent cycles might also be used/help prevent redundant work like
this.
> What happened is that an exponential runtime is reduced
There was no cycle for this crash. What happened is that an exponential
runtime is reduced to a linear runtime. Without this revision, ODR hashing
would have worked if the machine had enough memory and the user waited long
enough.
void foo(int a, int b) {}
When computing the ODR hash for functio
Does the ODR hashing have some sort of cycle breaking infrastructure -
so that if the same type is seen more than once (eg: classes have
members that have pointers back to the outer class type, etc) they
don't cause indefinite cycles? Should that infrastructure have caught
these cases & avoided the
Author: rtrieu
Date: Fri May 3 21:22:33 2019
New Revision: 359960
URL: http://llvm.org/viewvc/llvm-project?rev=359960&view=rev
Log:
Reduce amount of work ODR hashing does.
When a FunctionProtoType is in the original type in a DecayedType, the decayed
type is a PointerType which points back the o
