LLVM is also preferred because it has much cleaner internals than gcc (although gcc has gotten hugely better over the years). And of course, all production compilers become monumentally complex over the years (I once worked with Open64 - gah).

It's nearly impossible to keep optimizations secret. They are the easiest thing in the world to reverse engineer: just look at the output assembly. (And you can't exactly output obfuscated assembly because that would make the performance worse, nullifying the benefits of the optimizations.)

Though in a practical sense, if you've done the work of implementing useful optimisations and keep them closed source, it's not necessarily a trivial matter for others to recognise and replicate how exactly your optimisation is implemented, when it can be used, when it can't be, etc.

I don't get it.

Looking at output assembly language won't tell me anything about the algorithms behind solving the register allocation problem (aka: live data problem, which is a knapsack problem and/or graph-coloring problem IIRC).

I'd be able to see that yes, compilers are good at deciding which registers should hold which data. But that's not sufficient at actually learning how the algorithm / register selection process works.

that is for the simpler optimization. A more complicate optimization algorithm can generate quite different code depending on the inputs. So you might need many different input codes to fully explore the internal, similar to the problem facing by fuzzing and/or symbolic execution.