andrewng (Andrew Ng)
User

Projects

User does not belong to any projects.

User Details

User Since
Mar 2 2017, 6:37 AM (7 w, 4 d)

Recent Activity

Today

andrewng added a comment to D31604: [DebugInfo][X86] Improve X86 Optimize LEAs handling of debug values..

Sorry for the slight delay but only just got back from holiday.

Tue, Apr 25, 6:22 AM

Fri, Apr 21

andrewng added inline comments to D31604: [DebugInfo][X86] Improve X86 Optimize LEAs handling of debug values..
Fri, Apr 21, 3:02 AM
andrewng added a comment to D31755: [DebugInfo][X86] Fix handling of DBG_VALUE's in post-RA scheduler..

Rather than scanning forward for DBG_VALUEs, is there a more systematic way to find them? E.g., by iterating over USEs? If not, doing it this way is probably fine.

Fri, Apr 21, 2:56 AM

Tue, Apr 18

andrewng updated the diff for D31806: [SimplifyLibCalls] Fix infinite loop with fast-math optimization..

Updated test to focus only on the instcombine pass.

Tue, Apr 18, 11:06 PM

Sat, Apr 15

andrewng updated the diff for D31806: [SimplifyLibCalls] Fix infinite loop with fast-math optimization..

I've updated the comments to explicitly mention the MinGW-w64 case that encounters this issue and removed the unnecessary FunctionType related checks.

Sat, Apr 15, 10:05 PM

Wed, Apr 12

andrewng added inline comments to D31806: [SimplifyLibCalls] Fix infinite loop with fast-math optimization..
Wed, Apr 12, 6:53 PM

Tue, Apr 11

andrewng added a comment to D31806: [SimplifyLibCalls] Fix infinite loop with fast-math optimization..

gcc transforms the given C code to a call to expf(), just like LLVM, but then it looks like their inliner works a bit differently so the generated code ends up with a call to expf() rather than an infinite loop. With your patch, LLVM also generates a call to expf(). This seems weird... does MinGW's C library actually have an expf() function?

Tue, Apr 11, 10:42 PM

Sun, Apr 9

andrewng added a comment to D31806: [SimplifyLibCalls] Fix infinite loop with fast-math optimization..

Can you explain a little more how exactly we end up in this situation? Your example has undefined behavior according to the C standard.

Sun, Apr 9, 3:21 AM

Fri, Apr 7

andrewng created D31806: [SimplifyLibCalls] Fix infinite loop with fast-math optimization..
Fri, Apr 7, 5:03 AM

Thu, Apr 6

andrewng created D31755: [DebugInfo][X86] Fix handling of DBG_VALUE's in post-RA scheduler..
Thu, Apr 6, 5:27 AM

Tue, Apr 4

andrewng updated the diff for D31604: [DebugInfo][X86] Improve X86 Optimize LEAs handling of debug values..

Removed DWARF version checks as suggested by Adrian (thanks) and updated comments.

Tue, Apr 4, 5:38 AM

Mon, Apr 3

andrewng added inline comments to D31604: [DebugInfo][X86] Improve X86 Optimize LEAs handling of debug values..
Mon, Apr 3, 10:57 AM
andrewng created D31604: [DebugInfo][X86] Improve X86 Optimize LEAs handling of debug values..
Mon, Apr 3, 8:35 AM

Mar 17 2017

andrewng added a comment to D30835: [DebugInfo][X86] Teach Optimize LEAs pass to handle debug values.

Thanks for the review.

Mar 17 2017, 9:57 AM
andrewng added a comment to D30835: [DebugInfo][X86] Teach Optimize LEAs pass to handle debug values.

I have now split this patch and updated this review to contain the first part which fixes the codegen issue but doesn't preserve the debug values. I will work on a separate patch which will attempt to preserve the debug values.

Mar 17 2017, 7:35 AM
andrewng updated the diff for D30835: [DebugInfo][X86] Teach Optimize LEAs pass to handle debug values.
Mar 17 2017, 7:31 AM

Mar 16 2017

andrewng added a comment to D30835: [DebugInfo][X86] Teach Optimize LEAs pass to handle debug values.

Looks like this change does two things - fixes the "debug info affects optimization" and also does some work to improve optimized debug info quality? Might be worth separating this into two changes to make sure there's good test coverage/easier to review/etc?

I'm about to leave work now but I will look on Monday into whether separating this into two makes sense.

On further consideration, I think it makes sense to keep the patch as is because otherwise the first patch would be "lossy", i.e. the output would lose debug information. So in fixing the optimisation, ideally the debug information should be correct and preserved. However, if there are concerns with the "patching" of the debug information, then it might make sense to split the patch. What are your thoughts?

Mar 16 2017, 9:22 AM

Mar 13 2017

andrewng added a comment to D30835: [DebugInfo][X86] Teach Optimize LEAs pass to handle debug values.

Looks like this change does two things - fixes the "debug info affects optimization" and also does some work to improve optimized debug info quality? Might be worth separating this into two changes to make sure there's good test coverage/easier to review/etc?

I'm about to leave work now but I will look on Monday into whether separating this into two makes sense.

Mar 13 2017, 6:06 AM

Mar 10 2017

andrewng added a comment to D30835: [DebugInfo][X86] Teach Optimize LEAs pass to handle debug values.

Looks like this change does two things - fixes the "debug info affects optimization" and also does some work to improve optimized debug info quality? Might be worth separating this into two changes to make sure there's good test coverage/easier to review/etc?

Mar 10 2017, 11:10 AM
andrewng created D30835: [DebugInfo][X86] Teach Optimize LEAs pass to handle debug values.
Mar 10 2017, 10:01 AM