Page MenuHomePhabricator

llozano (Luis Lozano)


User does not belong to any projects.

User Details

User Since
Mar 20 2017, 6:22 PM (313 w, 1 d)

Recent Activity

Aug 9 2022

Herald added a project to D28638: [NDS32 1/46] Recognise nds32 in triple parsing code: Restricted Project.

Did anything happen with these NDS32 patches?
Is there any effort to add support for it?

Aug 9 2022, 10:37 AM · Restricted Project

Jun 3 2020

llozano added a comment to D77168: Add a flag to debug automatic variable initialization.

Do we have a mechanism bisecting pragmas? If yes, we can let that tool add #pragma clang attribute push([[clang::uninitialized]], apply_to = variable)

Not that I am aware of unfortunately. The whole point of having this patch is to add the ability to bisect programmatically, along the approach of using pragma as introduced in

If we have a mechanism bisecting pragmas, this option will not be needed.

Jun 3 2020, 12:30 AM · Restricted Project

May 29 2020

llozano raised a concern with rG840450549c91: [LV] Clamp MaxVF to power of 2..

We are seeing instances of an assert failing while building rsync and boost on Chrome OS. Bug

May 29 2020, 6:35 PM

Apr 17 2020

llozano added a comment to D77168: Add a flag to debug automatic variable initialization.
In D77168#1988122, @jfb wrote:

pragma clang attribute is interesting, but how do you apply that in a selective fashion to local variables (especially in a way that can be automated)? At first, I didn't think the goal for this should be to create a frequently used option for most end users, but I do think that it could be quite useful for more folks when debugging, especially if it is easy to automate (which optimization-fuel approaches are, while pragmas are not).

__attribute__((uninitialized)) for more selectiveness :)

Of course, not automated. In general we don't really automate compiler things of this sort, say UBSan. OptRemarks is the best we really have to dig into these things. One other option would be to truly randomize the init pattern: emit a handful of different byte patterns, and then see the crash caused by a different pattern, and track it back to which local variable got that byte pattern.

That's just it though. This technique is tried and true in other compilers/tools. Why should we let past history dictate whether to facilitate automation in the present/future? Rather than having to "track it back", you can let the tooling do it for you. It gets you at least a breakage related to this transformation, and the best part is you can fix that one, and then run it again to chase down further issues. All without modifying source code. I feel like I can't be the only one who has used these kinds of tools for debugging transformations before, hence why I feel so invested in making this easy for everyone (compiler devs and regular users). UBSan isn't as relevant as it can provide diagnostics for the particular instance in which it was tripped. If we wanted to do something similar for initialization, we would have to mark the uninitialized value and track down any potential use of it, which seems like a lot more complexity and decreased performance too.

Apr 17 2020, 4:25 PM · Restricted Project

Jul 22 2019

llozano added a comment to D64759: [CodeGen] Don't resolve the stack protector frame accesses until PEI.

Is there any progress on this?

Jul 22 2019, 11:31 PM · Restricted Project